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In this Issue 




A standard, easy-to-use, intuitive user interface for computer systems has been 
a goaf of system developers since the days of the EMIAC* computer The UNIX"^ 
operating system, which began life as a system for engineers only, has been a 
consistent target for various user- interface schemes. 

Before graphical user interfaces (GUIs) became commonplace, users interacted 
with computer systems via a character mode command-line interface. For UNIX 
systems, this command-line interface mode continued until the 1980s with the 
arrival of proprietary window systems. By 1988 the X Window System had been 
adopted as the standard window system for UNIX systems. Toolkits were created 
th at a 1 1 owed UNIX ven d ors to ere ate as m a ny diff e re nt pro p rieta ry user i nte r- 
face environments as there were vendors. Tiie article on page 6 introduces eight articles that describe 
how four UNIX vendors, who normally compete in the marketplace, collaborated on a user interface 
environment for UNIX platforms called the Common Desktop Environment, or CDE. This article explains 
how this environment is seen from three different viewpoints: developers who write applications to run 
In CDE, system administrators who must install and maintain these applications, and finally, end users 
who use these applications. 

Since UNIX systems are high fy networked, it is desirable that a desktop environment allow network 
transparency — the ability to launch applications and access data without worrying about where in the 
network these items are located. Thus, when the user selects an application |by double-clicking an icon) 
that happens to be on a remote system, the user environment automatically establishes links to the 
remote application server, allowing the user to run the appltcation as if it were located on the local work- 
station. The article on page 15 describes the underlying mechanisms that link icons to applications, and 
the tools that enabfe system administrators to integrate applications into the desktop environment 

In most cases today the icons on a graphical desktop are fairly intuitive. For example, if you drop a docu- 
ment on a printer icon very iikely the document will be sent to a printer of your choice. The article on 
page 24 describes the APIs (application programming interfaces) and databases responsible for defining 
the look and behavior of icons in the Common Desktop Environment. 

The world of online help has evolved from simpte out-of-context cryptic messages to media-rich, context- 
sensitive help messages. As the article on page 38 explains, the CDE help system is based on the easy- 
to-use HP VUE 3,0 help system. Like HP VUE 3.0, the CDE help system provides a language (HelpTag) for 
authors to develop help messages and tools for programmers to integrate customized help messages 
into their applications. The main difference between CDE help and HP VUE 3.0 help is the delivery format 
for help files, CDE help uses the semantic delivery language (SDL) as a delivery format for help files. SOL 
focuses on the semantics of a document. 

Many users are content with the special menu and icon customizations they have in their current HP 
VUE interface. Therefore, to allow users to keep their menu and icon customizations in CDE, a collection 
of utilities are provided to translate HP VUE customizations into CDE equivalents. These utilities are 
described on page 29. 

As mentioned above, the CDE project was a joint engineering effort between four companies that typi- 
cally compete In the marketplace. The companies are HP, IBM, Sun Microsystems, and Novell, All four of 
these companies produce computer systems that use the UNIX operating system as their system platform. 
Because of different cultures and development strategies, the joint effort presented some interesting 
and unique challenges. In the article on page 50, the author describes the mechanisms and procedures 
that had to be put in place to manage the CDE project. Because of the different development strategies, 
test tools, and verification methods, the test team had the greatest challenge in this mutti company project 
As the article on page 54 states, to ensure quality in the final product, strict guidelines were established 
at the beginning of the project. For example, rules were established for test coverage and assigning 
reponsibility when defects were found. 

" The EMIAC [Efectronic Numen'cai l-ntegrator And CalcufBtor} was developed in 1946, and is cnnsldsrad m have hsen the lirst fruly electrons computer. 
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One of the tools tfiat made testing the grapfiteal user mtefface of COE much easier is a test tool calleii 
Synlib. TYpically, an Image capture and compare technique is used to verifiy the various windows 
(screen states) of a GUL However, this technique is sometimes prone to inaccuracies. Althougti ttie 
image capture technique was used for COE testing, the majority of GUI testing used Synlib. Syniib 
reduces the need to use image capture for checking screen states because it employs 3 combination 
of position independent end position dependent data to manipulate and verify desktop items. Synlib is 
introduced m the article on page 54 and described in the article on page 62, 

For a mobile telephone to be competitive today it must supply full output power at a supply voltage of 
5.4 vofts (five NiCad cells ) with 40% efficiency and 0-dBm input power. It should also be inexpensive, 
small, have a long talk time, and be able to be manufactured in volume. These characterishcs determine 
the specihcations for the power module in a mobile telephone. The power module m a mobile telephone 
IS the output stage of the RF (radio frequency) amplification chein of the telephone. The article on page 66 
describes the design of a 3.5-watt power module for a GSM (Global System for Mobile Commumcations) 
mobile telephone, which satisfies all the specifications mentioned above. 

The article on page 73 is a good example of the wide range of products offered by HR The HP G1009A 
C-terminal protein sequencing system is a complete, automated system for the carboxy-terminal amino 
acid sequence analysis of protein samples. Using adsorptive sample loading and a patented sequencing 
chemistry, the HP G1009A is capable of detecting and sequencing through any of the 20 common amino 
acids. 

Time-domain reflectometry (TDR) is commonly used for determining the characteristic impedance of a 
transmission line or quantifying reflections caused by discontinuities along or at the termination of a 
transmission line. However, as the article on page 83 explains, TDR can also be used to measure the 
capacitance or inductance of devices or structures while they reside in the circuit The typical inductance- 
capacitance-resistance (LCR) meter cannot make these measurements accurately. The article shows 
how the HP 54750A oscilloscope and the HP 54754ATOR plug in card can be used to make these mea- 
surements. 

C.L Leath 
Managing Editor 



Cover 

A screen showing a typical collection of icons, panels, windows, and dialog boxes that make up the 
graphical user interface of the Common Desktop Environment. 



What's Ahc^ad 

In the June issue we'll have four articles on the HP 16505A prototype analyzer and articles on the HP 
PalmVue mobile clinical patient information transmission system, the HP Omnibook Pentium^^-^ PCl-based 
notebook computer, and the HP 38G graphing calculator for math and science classes. There will also be 
a paper on developing an application server in a highly networked environment. 

UNIX IS a regtsEared trademajk i.r> the Uniied Swiss and other countries, IrcBflsed excluswsJy through X/Open Compariy Lrmpted. 
Pentium js a U.S. registersd ifademark of Intd Corporattan. 
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A Common Desktop Environment for 

Platforms Based on the UNIX® 
Operating System 

User interface technologies from four companies have been combined to 
create a single UNIX desktop standard that provides a common look and 
feel for end users and a common set of tools for system administrators 
and application developers. 

by Brian E, Cripe, Jon A, Brewsterj and Dana E, Laursen 



Until the early 1980s most users interacted with their com- 
puters \ia chaiacter-mode interfaces — they typed in com- 
mands. What happened to change all this was the arrival of 
proprietai'j' window systems. HP's first window system was 
embedded in the hitegral Personal Computer.^ By 1988 the 
X Window Sysrenx liad l^een adopt etl as a standard for ina- 
cliines ruimmg the l.'>JIX operating system. However, avail- 
able user mterface toolkits, such as HP's CXI widgets, w^ere 
proprietiu^'. Hiese toolkits provided items such as scroll bars 
and pop-up menus, and they allowed software developers to 
create applications that had a consistent look and feel. By 
1990 two stable toolkits had emerged^ OSF/Motif and Open- 
Look, t 

The stage was now set for proprietary user enviroiuuents. 
A user environment is a collection of programs used by the 
end user \o manage lllesn invoke applieationsj and perforin 
routine tasks sueli as edit text tiles and send aiui receive 
email. HP dehvered its fii^st version of HP \TJE (Visual User 
Environment)^ in 1990 with subsequent upgrades coiituiuing 
to this day. 

hi March of 1093 representatives from Hewlett-Packard, IBM, 
Smi Microsystems, and Novell agreed to create a common 
user environment for I'NIX platfonns (see the aiticle on 
page 50). This joint iiutiati\'e resulted m the speciBcanon and 
development of the Conunon Desktop Enviroiuuent (CDE). 
ODE accomplishes two things: fust, it adopts OSF/Motif £is 
the pritKipd user interi'ace toolkit for INIX sj^ stems, ajid 
second, it establishes tlus rich new emironment and frame- 
work as a standard user envu onment, 

CDE is based on the X Window System from the X Consor- 
tium and the Motif graphical user interface from the Open 
Softi^^are Foimdarion. Fig. 1 shows how tJiese teciuiologies 
fit together. 

The X W'lndow System (X) components include: 

• X seiven Tliis program wTites directly to the user*s display 
haidw^are. 

• Xhb. This is a hbrary of function calls for communicating 
with the X sender. Xlib deals ^dth low-ievel concepts such tis 

t Op&nLpDk 15 the X Wincipw Sysiem xnoM tram Sun Micros^fStfims. 



rectangles, arcs, and fonts. It does not know about higher- 
level concepts such as menus and scioll bars (he., interface 
widgets). 

• X protocol This is the data stream that comniunieates 
between Xlib atid the X .sener. This data stream can be 
passed across a network, which gives X the abihty to nui an 
application on one system and display the user interface to 
another system. 

• Xt. This is the X toolkit, which pro\qdes a framework for 
definuig and uUegratiiig user iutert'aee widgets. 

The Motif component is Xm, wluch is the Motif libnuy that 
provides a rich collection of user interface widgets such as 
chaiog boxes, menus, buttons, scroll bars, and text eiliting 
panes. 

Different Views of CDE 

The rest of this article provides an overview of CDE from 
three different t;ierspectives: the end user w^ho uses C'DE but 
does not care about its internal design, the softwaie devel- 
oper who is writing apphcations that need to be integrated 
with CDE, and d\e system admuustralor who is responsible 
for managing systems that nui CDE. 




Fig. 1. CDE iircJiitet ture. 
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End- User's View 

Putting together a user emiroimient and application frame- 
work such as CDE always forces one to be precise about 
reijuiremejirs. Many of the dming inputs for the CDE project 
tunied out to be based on the following end-user require- 
nients: 

• Completeness- CDE needs to be a full-service environment 
covering evervlhitig from login tti logout . Tim includes se- 
curit>' and anilu^ntK'aUt>n. wUKiowing, a|>plk*?uion launching, 
rile luiUiageiiient, email and so on. 

• IntegrarioiL CDE jiarts and services need to work together 
seamlessly. For example, it should be possible to mail a 
meeting notice with a calendar appointment in it^ allowing 
tJie recepienlK to add the event easily to their calendars. 
Also. CDE utilities need to use CDE APIs (e.g., help, drag 
and drop, etc, ) not only to be consistent with each other, 
but to be sho\^'case components sliow irig the results of 
proper use. 

• Compatibility. Previous aijpltcations need to continue to 
rttn- This Is true for OpenLook, Motif, and terminal-based 
software. For HP VIJK users, w^e were ver>^ interested in 
ensuring that conversion tools could be created to tuovc 
conjiguraiion information into CDE. 

• Ease of use. The resulting environment needs to be guided 
by a standard set of usability principles and tested for 
usability deft^cts. This work took place at ttie early stages 
and during every step of the CDE project. 

Getting agreement on these fundamental end-user require- 
ments was critical given the nature of our extenciecl uujlli- 
con^pany develot>ment team. Many of t lie uiore difricult 
project decisions recitiired coming back to t hese basics. For 
example, die drag and drop aj'cliilecture liad to tie reworked 



se\^eraJ times to accomplish the inte^^on ambitions of the 
team. 

The cover of this issue and Fig, 2 show a t>pical CDE user 
interface, and Table I lists all the en<^i-u.ser components, 
some of which are shown m Fig. L 

Basic End-User 'Disks 

Tiie first thing a user does when approaching CDE is log in. 
It is the CDE lo^ service that authenticates and authorizes 
user access to the system. This gatekeeper for the I'NIX 
sj'steni then invokes tl>e basic session components such as 
tlie iviu<low manager and file manager. The users previous 
session can also be automatically restored. This allows 
items such as rumiing applicadons, color settings, itnd the 
graphical desktop arrangement to be retained from ttie logout 
of the previous s^sion. 

Once the user is loggetl in, the file tnanager is used to find 
and organize ^lata files. Piles can be dragged out of tlie file 
manager m\<\ dropped in many interesting places such as the 
printer Files can be moved and copied by dragging them 
at)out. File icons can be placed on the m<un screen as if the 
screen were a desktop. A files ty^je (document, spreadsheet, 
intage, etc. ) c;m be determined by its icon, mxi v^ariotis t^^ie- 
specific actions can be invoked via a pop -up menu that is 
rnacie available for each icon. f\>r ex^unple^ e<iitii\g a graphics 
image and \iewing that sante image might require two 
different apphcations and thus two different actions in the 
pop-up actions nieniL The file manager also iiUows different 
\iews of the filv directories, sui li as a tree view (contaimuent. 
hierarchy) and a rnil file properties view (size, security, 
etc.). Files ran be found by manually browsing Ibrougfi the 




Front Panel 



Fig, 2. A iypkiil CDE nspr IntprfHr^. 
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Component 

Login Manager 

Session 
Manager 

Winilcjw 
Manager 

Workspace 
Manager 

Front Panel 

Style Manager 

File Maj>ager 

Application 
Manager 

Ibxt Editor 

Icon Edito!* 

Mailer 

Calendar 

C'alcnlator 

Tiemiinal 
Emulator 

Action Creator 

Prijit Manager 



Table f 

End-User Components 

Function 
Graphical login and autlientication 
Logout to login session save and restore 

XI 1 Windows compliant window 
manager 

Window grouping and task switching 

ITbiquitous services access and work- 
space switching 

Customizat ioT> and configuration 

File manipulation sendees 

Application cUscoveiy and launch 
services 

ASCn text file editor 

nie type icon creator and editor 

F\ill MIME compliant multipart email 
facility 

Personal aitd group time manager 

Financial^ logical, and scientific n^odes 

VT220 type character mode support 

Linking behavior to specific icouf^ 
Multiprinter-aware print submission tool 



directories or via a finding service that works with name or 
content matcluiig, A found file can then be automatically 
placed on the desktop. 

Applications can be launched in a number of ways. Simply 
double-clicking a data file icon and allowing CDE to launch 
the conect application t^irh that data file as its m'gunient is 
usutdly the most convenient ajiproach. However, sometimes 
Rinning an application directly is more appropriate. Tlie 
applications themselves also show up 3s icons that can be 
moved about, organized, and double-clicked for invocation. 
The-se application icons arc initially foimd in the application 
manager, which is really just a file manager window onto the 
applications directoo'. A user can di'ag the ap]ilication icons 
into any tether directory or even onto the desktop. For im- 
portant and conuuonly used apphcations, the icon can be 
directly installed into the front panel for easy access. 

Tl^e article on page 15 describes the data structures in- 
volved in liuking applications, icons, imd actions together 

Task management in CDE is much like any other windowing 
environment in that it has various ways to control the win- 
(lowing behaiior of the numing appU cations. However, tiiere 
is a m^or enhancement in CDE ctilled workspaceH. The 
multiple- workspace paradigm supported by CDE allows a 
user to svv itch between nmltiple screens full of application 
wmdows. This allows each collection of windows to be 
ti'eated as a group (the default is four workspaces). End users 
can use workspaces to collect together groups of windows 



for specific tasks. For example^ one works^iace could contain 
all the windows associated with a remote system, while 
another workspace could contain windows for the user's 
desktop publishing tools. 

Workspace switching is very fast, typically less than a few 
tenths of a second, and is accomplished by pressing a single 
button witliin the front panel. Each worksjjace has its owm 
backdrop, which is usually color-coded to match its button. 
The vvorkspaces are also nattied and can be created and 
destroyed at any time by live user 

The front panel is usually located at the bottom of the screen 
(see Fig. 2). It is available in all workspaces and provides 
access to important and frequently used services, These ser- 
vices include: 

• Clock and calendar functions 

• Personal file space {file majiager acce.ss) 

• General apphcation space (at>plication manager access) 

• IHgh-use apphcation and data file access 

• Mail facilities 

• Workspace management controls 

• Printer access 

• CDE coitfigiuation controls 

• Help facilities 

• T^ ash can for deleting files 

• Screen locking aiid logout services, 

Tlie fi:'ont panel is a unifying tool for collecting important 
services that are otherwise left scattered and haid to tlnd. It 
is also a distinctive visual feature known to the development 
tcEmi as a sigimture vimial in that it distinguishes the ma- 
chine rumiing CDE from other machuies. 

End-User CDE Utilities 

CDE has a number of utility progratns that support, specific 
end-user tasks. The following are some of these utilities. 

Text Editor, Tliis is a simple ASCII text editor that is neatly 
integrated into CDF] so that drag and drop, help, and general 
Motif text behavior ai e seamlessly available to the end user 
Text, fomiatting, spell checking, and cut. and paste services 
aie also available. 

Mailer This is a highly mtcgrated set of services that has full 
drag and drop behavior \vith respect to folders, messages, 
ai^d attachments. The (bUowing scenario illustrates the ser- 
vices integi'ated with the mailen 

The front t>aners mail icon is pressed, biinging up the user's 
in-box. A message is diagged from tJie in-box to the front 
panel's printer icon. Another message is dragge<l to a mail 
folder icon v\ithin a file manager for saving. A file is dragged 
froEu tJie file manager to the mail icon on the front panel for 
sending, Fintdly, a message being read has a graphics attach- 
mein that is double-elicked to mvoke the graphics viewer. 

Thus, from the CDE mailer the user can print a message, 
save a message to a file, view tiie graphics in a message, and 
compose and send a message. 

Calendar. Tlie calendar facility is a i)ersoital tool for managing 
time imd to-do items. It is "gi'oup aware" so that the user 
ciin examuie and seaicii for meeting opportimities with col- 
leagues. Individuals can control ti^e privacy of their own 
schedules. Meetbigs can be emailed via the drag and drop 
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mechanism, and the caJendar view can be flipped between 
day, week* month, and six-month views. 

Term mil. Tliis tool supports ciiaracter-mode appUcatiuns 
j s*niie of which predaie window s\'stems). The CDE lemiinal 
emulator beha^^es like a DEC* \T220 terminal with minor 
changes consistent with ANSI and ISO standards. FYiU cut 
and paste lieha\ior %1Ui the rest of the desktop is built in. 
The core feature of this emulator traces its ancestry back to 
HP's bilegral Personal Computer which !iad tIP s first win- 
do wii\g system and thus HPs first terminal emulator for the 
UNIX operating system. 

Software Developer's \lew of CDE 

To the software developer, CDE is composed of two distinct 
components: the X/Open* standard and CDE product imple- 
mentations. The X/Open standard defines the components 
that must be present on jmy system that claims to be CDE- 
comphaiit. HP's CDE prodtict. like CDE products from other 
vendors, must support the interfaces defined by the X/Open 
CDE standard, but may contain additional functionality 
For example, many vendors have enhanced CDE to pro\ide 
backward compatibility with previoits proprietary products. 
Software develD]>ers siiuuid tje cautious when usir^g features 
of a CDE i>t*oduct litat iire not jjan of the X/Open standard 
tjecause they may not be portable to ail CDE systems. 

The m^jor benefits that CDE provides to the developer are: 

• A single GXJl toolkit (OSF/MotiQ that Is supponed by all 
oi^jor UNIX vendors 

• Tools and libraries to help build an application 

• Mectvanisms to ititegrate an appUcatiou with the desktop 
environment 

• Mechanisms to mtegrate applications with each other 

Table IT lists the components available in CDE that enable 
developers to integrate their applications into Cf>E. 
Appendix A, on paj^c 11, contains a contplele list of all the 
CDE APIs, which enable developers to build applications 
based on CDE. 

CDE defines thi^ee levels of application integration from 
wliich the developer can choose: basic, recommended, and 
optiond. Basic integration (*onsists of the minimal integi'ation 
stt^ps that allow a user to access an ai>piication fixmi the 
desktop environment instead of a conuiiand prompt in a 
tenninal window. Recotimiended integration requires more 
effort by the developer but allows the application to be fully 
consistent wit It CDE and other CDE apphcations. Tlic fntal 
level, t>pUonal inlegratiun, is not necessary for most apjilica- 
tions but is useful for a])plications that need to perform 
specialized tasks. 

Basic Integration 

Basic ititcgration allows an apphcation and its data files to 
be managed l>y CDE. This management includes: 

• Finding the application and invoking it using an icon in the 
applicaticm manager 

• Identifying the applicEition s data files witli a ui^lque icon 

• Loading a data file into the aj)[>lication by dragging atul 
dnip|>ing the file icon on the application icon 

• Invoking the appUt-ition to [Jtint a data file l)y dragging and 
druiJping the filp ic^jn nu a printer icon 

• Using the style manager to specify colors and fonts fur t lie 
applit^atititi 



{Component 
Help S>*stem 

Motif Toolkit 

Custom Widgets 

Terminal Widget 

Dlksh 

Data Interchange 

ToolTalk' 

Data Taping 

Actions 

Font Guidelines 

I n r em at ! onalization 
Guidehties 

Client/Server 
Guidelines 



Table M 
Developer Components 

Purpose 

\lewer, APL and administration 
fools 

OSFAlotif version lJ?.3 plus some 
LtA repairs 



SpinButtofi and CamboBw 
(taken from Motif 2.0) 

For adding terminai emulation to an 
^plication 

A GUI dialoging and scripting faciiit>' 

Dri^ antl drop conventions, proto- 
cols, and APIs 

A standard general-purpose message 
passing service that enables tight 
integration bet\^'een separate appli- 
cations aitd CDE components 

API for access to the desktop engine 
tyi^king sen-ices 

API for access to the desktop 
invocation services 

Conventions for standard font 
interactions 

(X^eniew jmd reconciliation of 
relevant stjmdards m\d style guides 

Network execution and distribution 
model 



• Locating infomtation about the application in the help 
majtager, 

Basic integration can be accomplished without any modifi- 
cations to the application's source or executable files. The 
steps for peiforming basic integration include: 

• Defining an aj)plication gnnip for the ajjplication manager 
that will hold the a|>i)iicafJon 

• Defining the applicat ion's icons atKl giving them the c^orrect 
ilouble click antl drag at^l drop behavior by creating new 
CDE actions and data tyE>es 

• Removing color and tont specifications from the applica- 
tion's defaults file so that it will use the default colors and 
fonts specified by the CDE style manager 

• Installing configuration files for Uie apphcadon in Uie slan- 
dm-fl lUe system locations and registenng it witli die desktop 
using the dtappintegratB cotnnuind (This conunand is r>^>ically 
invoked by the apphcation's installation script, ) 

• Creating and installing any appropriate application informa- 
tion as desktop help files. 

Recommended Integration 

Reconmiended integration includes additional steps that are 
necessary Icj make the application fully integrated intfj CDE 
and consistent with other apt'litatifms. This level of intt*gra- 
1 ion requires modifications to the a[)plicaf itrn's source code, 
Jiiit in return it provides die following benefits: 

• Tlve user can access context -sensilive online help from 
within the application using the CUE helj) system. To 
achieve this the application must use Ihe help system AFL 
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• The application can achieve tight integration with other 
appUcadons using ToolTallf messages. For example, aii editor 
appUcation that supports tlie media exchatige message suite 
can be used by other ap|jlit^atioiLs lor editiri^ rlata objects. 
To achieve Uiisthe applicalifjn muKt use die TotjlTalk 
messaging API and support one or riioie ol die standard 
message suites. 

■ The user can log out with Ihe aj>piicatioji running and upon 
login the application will be automatically restful ed and 
restored to its previous state. To achieve this the application 
must be able to read and wrile session files that define t he 
apphcation s state, and it must use the session nianagement 
API for controlling this behavior. 

• The user can move data into or out of a innning application 
using the drag aud tirop facyity. To achieve thus the apphca- 
tion must use ifie drag and drop API. 

• Tlie apphcation user interface can be tianslated into other 
languages wilhoul modifying tht^ source code for tlie appli- 
cation. To at hieve tliis the apphcation must follow the inter- 
nationaJlssation guidelines. 

• The application can be displayed on a remote Tvorkstation 
or an X lenninal and be tissured of getting the expected 
fonts. To ac* ill eve ttus the application miLst access its fonts 
iLshig tJie standard font names defmed in the font guidelines. 

Optional Integration 

Applications with unique needs may choose to use the 
optional CUE integration facilities. Applications are nol 
required or exi>ected to use any of these facilities, but some 
applications will find them usefuj. These facihties include: 

• Additional Motif widgets such as Spin Box and ComboBoK 

• Data typing fLmctions ttiat enaljle an apphcation to determine 
the type and attributes of fdes and other data items in a 
manner consistent with CUE and other applications 

• Action invocation fujictiojis that enable an application to 
invoke odier applications 

• Monitor and control fimctioi^s for the placement of apijlica- 
tions in the user's workspaces 

■ A termuial emulator widget that can be used to add a con- 
ventional L^NIX command window^ to the application 

• A text editor \^i<Jget that allows addmg a text editing 
window to the apphcation. which is more pow^erful dian 
tile standard Motif text editor widget 

• An API to access calendar and srluHiuling capabilities, 
winch is an implementation of riie X.4(H) iissociation c^ilen- 
dai'uig and scheduling AI^l 1.(1 

• An enhanced version of Koni shell which provides access to 
CDE APIs from an inteipieted script liinguage. 

More infonnation about these integration teclniiques can be 
found in references 3 and 4. 

System Administrator's View of CDE 

CDE greatly simplifies I he Ijurden of a UNIX sj^stem admin- 
istrator bi-cause it jn'o^ldes a cotYsistent set of capabilities 
and corrfigmation mechanisms across \1j1uaUy all TNIX 
systems. Tasks that an administrator of a CDE system miglit 
perform include configuring the behavior of CDE^ achninis- 
tering CDE m a netw^orked environment, and admhustering 
apphcations. 

Cunfiguring CDE. CDE is a liighly conBgmable emironment. 
Many of Uie custoniizations that a user can choose to do to 



configure a personal environment can also be done by a 
system admin istrator for all users. Some examples of pos- 
sible configurat ion changes include the ability to: 

• Customize tlie appearance of Ihe logui screen 

• Modify the set of applications that get automatically started 
when a user first logs in 

• Add or remove printer icons from the print manager 

• Customize the contents of the front p^mel 

• Lock all or portions tjf the front ]janel so that they cannot be 
modified by the user 

• CustomiKe the set of controls embedded in window^ frames 
and modify their behavior 

• Modify the menus available from the root window of the 
display 

• Modify the keyboard bindings and accelerator keys used by 
applications 

• Customize the default fonts, colors, and backdrops used by 
CDE and apphcations. 

For more uiformation on any of these tasks see reference 4. 

AdiTiinistering CDE in a Networked Erivirooment. CDE is 

designed to work w^^U in a highly networked eru ironrnent. 
The architecture of the desktop lets system adnunistrators 
ffistribute computing resources throughout the network, 
including applications, data files for applications, desktop 
session scr\ices (desktop apphcations such as the login 
manager and file manager), and help sei-vices. Help data 
files can be put on a centi^al help server 

"Pvpical tasks performed by die administrator of a net.w^ork 
nrnniug CDE include: 

• Installing the operating system and CDE on a network of 
systems, some of which might petf orm specialized tasks 
such as act as an a;) plication seiver 

• Configmlng the login manager so that w^orkstations or 
X temhnals have login access to the ajipropriate set of 
systems 

• Coiifigiuing the chstributed file system so that ail systems 
liave access to the necessary set of data files 

• Installing and configuring devices such as printers so that 
they aie accessible from die desktop environment 

• Configmlng application seivers that run app 1 i cat i tins on 
behalf of other systems in the network 

• Configuring other servers such as database senders Oi^ help 
servers. 

CDE includes a number of daemons. System administratoi^ 
often do not need to lie aware of these daemons because 
rhey are installed iuid configured automatically when CDE is 
installed. However, in some situations system administrators 
may need to use the infonnation in tlie manuals and man 
pages to create some nontypical configurations. 

These daemons include: 
■ dilogii. The login manager, which provides login sei-vices 
to the w^orksration ui X tenuiuid 

• dtspcd. The subprocess control daemon, which provides 
remote conunand invocation 

• rpcttdbsBiver. The TooiTalk database server, which is used 
by the TooITalk messaging system and perfom^s filename 
mapping 

• ttsessEon, The ToolTklk message server, which provides 
message passhig 
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• rpcxmsd. The caJendar daemon, which manages the caiendar 
databases. 

More information about these daemons can be foimd in 

reference S. 

Admiiristertng Apphcaticins. The networking capabilities of 
the HP'IX' oi>eraiirtg system, the X Window' Sysiem, and 
CUE can be iiseti to create mimy different application exe- 
cution configuraDons. The simplest confignrarion is local 
application execution in which applicalions are installed on 
liie local disk of a workst^on and executed locally 

A v^ariation of this configuration is to install applications on 
a disk on a central file server and Lhet\ mount that disk on 
other workstations. Each worksiatioti accesses the apipliea- 
lion's executable and configunition flies across the network, 
but executes them locally. This configuration reduces the 
total amount of rc*quired disk space because multiple work- 
stations are sharing a single copy of the application files. 

Another approach is to use centralized application serv^ers. 
This configuration uses the clientyserver capabilities of the 
X Window System to execute the application on one system 
and display its user interface on another workstation or X 
temiinaU 

Application ser\''ere are a good solution i o the problem of 
giving users access to applications thai have special nin-time 
rcQuirements. For example, if usei*s need access to an appli- 
cation that only nins on HP-l'X BXK an HP-UX 8.0 application 
server can be cheated and accessed from workstations run- 
ning HP-UX 9,0. 

CDE makes these disdibuted application enwonments sim- 
ple to use by rejiresenting all aiiplitations as icons iti the 
application manager. The ust r does not need to know orcai^e 
wht^ther the apphcation is installed locally or on a renioJe 
application server. 

CDK also makes these disfriliuted configurations easy to 
crejite and administer. AtJt>hcations are iiistalled the same 



way whether they will be used locally or accessed remotely. 
When a workstation is configured to access another s>^iem 
as an apphcafion server, all of the applications on ibat system 
that have been registered with CDE automatically liecome 
available. The article on page 15 provides a more detailed 
discussion about CDE apphcation administration tools- 

Summajir' 

Tl*e HP VUE user will find much to appreciate in CDE. CDE 
retains the best end-user features of HP WE, such as m^ork- 
spaces and tlie iconic desktop behavior, CDE adds many 
new end-user senices, such as an mtegrated mailer and a 
calendar system. Tlie system administrator gets a rich and 
new standard set of configuration tjptions that also shares 
much of the HP VUE approach. A software developer has 
optional access to a new programming framework to take 
tub amage of deep emironment integration. Other tlian the 
help faciht^'. these programming senices were not available 
iLspaitofHP\TlE. 
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Appendix A: CDE Application Programming Interfaces 



This appendix lists the CDE libraries and header files that contain the 
CDE APIs, 

Desktop Services Library (NbDtSvc) 

Desktop Initialization APIs. The desktop services library must be 

initialized with DtAppinitielizel) or DtJnitiaiizeO before an appiicaiion can 
USB the APIs for action invocation, data typing, drag and drop, screen 
saving, session management, or workspace management. 

' #iEt elude <DVDt.h> 

' Dt(5); Miscallaneous desktop definitions. 
' DiApplnit3alize(3). 0tlrimalt2e(3) Desktop servicer library initialization 
functions, 

At:tiQB I nvo cation APIs. These APIs provfde a pp I teat ions access to the 

(leskio[i action database to query achon attributes and to invoke actions. 
The DtActiontnvokei) function selects the correct desktop action to invoke 
based on its arguments and actions in the database The DtDbLoadO and 
DtDbRelGadNotifyd functions apply to the shared database for actions 
and data types. 



• linclude <Dt/ActJcn,h> 

• DtActiar(5): Action service definitions 

• DtActionCaltbackProcOl; Notifies application that the status of an action 
has changed 

• OtActionDescriptionO): Obtains the descriptive text for a given action 

• DtActionExistsOk Determines if a string corresponds to an action name 

• DiActionlconO)' Gets the icon information for an action 

• □lActionlnvokeiai Invokes a CDE action 

• DtActionLabellS) Gets the focaliiable label string for an action 

• DtDbLoadO): Loads the actions and data types database 

• DtDbReloadNotifylS): Registers callbacks for changes to actions and data 
types database. 

Data Typing APIs. Data typing APIs provide applications with access to 
the desktop data type database to query data type attributes and to 
determine the data type of files, buffers, and data. 

• #in elude <D|/Dts.h> 

• DtDts(5): Provfdes data typing definitions 
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• DtDtsBLjfferToAttributeList(3l; Gets a list of data attribytes for a byte 
stream 

• DtDtsBufferToAttribLiteValuep}: Gets a Single data attribute value tor a 
byte stream 

• DtDtsBufferToDataTypeOS Gets the data type for a byte stream 

• DtDtsDataToDataTypeO): Gets the data type for e set of data 

• DtOtsDataTvpelsAction{3}: Deternnines if the data type is an action 

• DtDlsDaiaTypeNamesOl: Gets a list of available data types 

• DtDtsOaiaTypeToAttrFbuteUstO): Gets a list of attributes for a da [a type 

• DtDtsDataTypeToAttributeValue(3l Get.s an attribute value for a specified 
data type 

• DtDtsFi[eToAttributeListf3) Gets a list of attributes for a file 

• DtDtsFilBTDAttributeValue{3): Gets a specified attribute value for a file 

• DtDtsFfleToDataTypeOS: Gets 3 data type for a file 

• DtDtsRndAttribute(3k Gets a specified list of data types 
» DiDt3FreeAttrihuteList(3) Frees a list of data attributes 

• DiDtsFreeAttrihuteValueO): Frees a data attribute value 

• DtOtsFreeDataType(3}: Frees a data type pointer to memory 

• OtOtsFreeDataTypel\fames(3): Frees a list of data type names 

• DtDts[sTrue{3|: Returns a Boolean value associated With a string 

• DtDisLoadDataTypest3); Loads and initializes the data types database 

• DtDtsReleaseO): Frees memory associated with the data types database 

• DiDtsSetDataTypelSJ: Sets the data type of a directory. 

Drag and Drop APIs. The drag and drop APIs are a convenience and 
policy layer on top of Motif 1 .2 drag and drop. The drag and drop APIs 
manage the configuration and appearance of drag icons, define a transfer 
protocol for buffers, enable animation upon drop, provide enumeration of 
targets for text and file transfers, allow dual registration of text widgets 
for text and other data, and provide priori lizt^d drop formats, 

• #fnclude<Dt/Dnd.h> 

• DtDnd(5): Provides drag and drop definitions 

• DtDndCreateSourceicon(3). Creates a drag spLrce icon 

• DtDndDragStart{3) Initiates a drag 

• DiDndDrapRegisterlS}: Specifies a drop site 

• DtDndDropUnregisterfS): Deactivates a drop site. 

Screen Saver APIs. 

• #include <DtySaver.h> 

• DtSaver(5)" Provides screen saver definitions 

• DtSaverGetWJndows(3(; Gets the list of windows for drawing by a screen 
saver application. 

Session Management APIs. 

• Ti'include <Ot'Session.h> 

• DtSession{5}. Provides session management services definitions 

• OtSessionRestorePath{3}: Gets s path name for the application's slate 
information file 

• DtSessionSavePathO) Gets a path name for saving application state 
information. 

Workspace Msnagement APIs. The workspace management APIs 

provide functJons to access and modify workspace attributes and to 
request notifi cation of workspace changes. 

• #inclLide <Dt/Wsm.h> 

• DiWsml5l: Workspace manager definitions 

• DtWsmAddCurrentWorkspaceCallback(3): Adds a callback to be called 
when the current workspace changes 

• DtWsfnAddWorkspac8Functions(3): Adds workspace functions for a 
window 



• DtWsmAddWorkspaceModifiedCgllbackO): Adds a callback to be called 
when any workspace is changed 

• DtWsmFreeWorkspacelnfoO): Frees workspace information 

• DtWsmGetCurrentBackdropWindow{3) Gets the backdrop window for 
the current workspace 

• DtWsmGetCurrentWorkspaceO}: Gets the current workspace 

• DtWsmGetWorkspacelnfoO): Gets detailed workspace information 

• DtWsmGetWorkspaceList{3}: Gets the names of the currently defined 
workspaces 

• DiWsmGetWorkspacesOccLipiadO). Gets the workspaces in which a 
window resides 

• DtWsmOccupvAIIWorkspacesO} Puts a Window into all workspaces 

• DtWsmRemDveWoi-k^pBceCallback(3) Removes a workspace callback 

• DtWsmRemDveWDrkspaceFunctionsIS): Hemoves a window's workspace 
function 

• OtWsmSetCurrentWorkspaceO): Sets the current workspace 

• DtWsmSetWorkspacesOccupjed|3): Sets the workspaces in which a 
window resides. 

Help Wirlget Librarv (libDtH&lp) 

Help Utility APIs. Tiiese APIs are used to manage application help. 

• #include<Dt/Help.h> 

• DtHelpl5l Help services definitions 

• DtHelpReturnSelectedWidgetldiSI: Selects a widget or gadget 

• DtHeipSetCataJogNameO); Assigns the name of the message catalog to 
use for help services 

HelpDialog Widget API. The DtHelpDialog widget provides users with 
the functfonality for viewing and navigating structured online information 
(CDE help volumes). This functionality includes text and graphics render- 
ing, embedded hypertej^t links, and various navfgaipon methods to move 
through online help information. The widget supports rendering of CDE 
help volumes, system manual pages, text files, and character string values. 

• #include <O^HeEpDi3logJi> 

» DtHelpDialog(5|: DtHelpDialog definitions 

» DtCreateHelpDiabgiS): Creates a general DtHelpDialog wjdget 

» DtHelpDialogj3): The DtHelpDialog widget class. 

HefpQiiickDialog Widget APIs. The DtHelpQuickDSalog widget provides 
users with the same functionality as the DtHetpDialag widget. The differ- 
ence here is that the functionality is for the quick dialog widget. 

■ #inctude <Ot/HelpQu[ckD.h> 

" DtHelpOuickDjS): DtHelpQuickDiafog definitions 

• DtCreateHelpQuickDialDgl3): Creates a DtHelpQuickDialog widget 
" DtHelpQuickDialog(3): The DtHelpDuickOialog widget class 

» DtHelpQuickDialogGetChild(3|; Gets the child of a DtHelpQuickDialog 
widget 

Terminal Widget Library (UhDtTermt 

Terminal Widget APIs. IIig DtTerm widget provides the core set of 

functmnality needed to emulate an AMSI X3.64-1979-and ISD 
6429:1 992iE}-style temiinaL such as the DEC VT220, This functionality 
includes text rendering, scrolling, margin and tab support, escape se- 
quence parsing, and the low4evef, operating-system-specific interface 
required to allocate and configure a pty or streams pseudoterminal de- 
vice and write to the system's utmp device. 

► #inciude <DvTerm.h> 

» DtTerm(5l: DtTerm widget definitions 
» OtCreateTermOj: Creates a DtTerm widget 
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• DiTefTn(3K DtTemi widget class 

• DtTemiDisplavSendOt Sends data to a OtTerm widget s display 

• DtTermlnFti3liie^3] Prevents accelerators froin being installed on a 
OtTenn widgei 

• OtTermSubprocReaplSJ Allows a DtTerim widget to clean up after subpru- 
cess termination 

• DtTemiSubprQcSemlO^ Sends data Id a DiTemi widget s sut^rocess 

Desktop Widget Ubrary (HbDtWidget) 

Editor Widget APIs. The DtEditor widget supports creating and editing 

text filas |f gives eppJications running in the deskiop envtronmenta 
consistent method (or editing text data. The widget consists of a scrolled 
edit window for text, dialogs for finding and changing text and an optional 
status line. Editing operations include finding gnd changing text, simple 
fomiatting, spelt checking, and undoing the previous editing Dperation 

• #in[:tude <0!/Editor.h> 

• OtEdrtor(5) Editor widget definitions 

• OtCreateEditorO): Creates a DtEdttor widget 

• DtEditor(3) OtEditorwidger class 

• OtEditorAppendO) Appends data to a Mditor widget 

• DtEdftorAppendFromFileO): Appends data from a file into a DtEditor widget 

• DtEditorChangep): Changes one or all occurfences of a string in a DtEditor 
widget 

• OtEditorCheckForUnsavedChangesO}; Reports whether text has been 
edited 

• DtEditDrC[earSelectEor(3): Clears the pnmary selection m a DtEditor widget 

• DtEditor CopyToCiipboardO)- Copies the primary seEection in a DtEditor 
widget 10 the clipboard 

• DtEditorCutToClipboardO): Copies the primary selectinn in a DtEditor 
widget to the clipboard and deletes the selected text 

• DtEditor Delete Selection 13): Deletes the primary selection in the DtEditor 
widget 

• DtEditorDeseiectO) Deselects the current selection in a DtEditor widget 

• DtEditorDisabieRedisplayO} Temporarily prevents visual update of a 
DtEditor widget 

• DtEdimrEnabieRedisplavIS) Forces the visual update of a DtEditor widget 

• DtEditorFindO): Searches far the next occurrence of a string in a DtEditor 
widget 

• DtEditorFomiatiS} Formats all or part of the contents of a DtEditor widget 

• DtEditorGetComents{3} Retrieves the contents of a DtEditor widget 

• Dt£ditorGetlnsertionPositionj3^: RetriEVes the position of the insert cursor in 
a DtEditor widget 

• DtEditorGetiastPositionfS): Retrieves the position of the last character in 
a DtEditor widget 

• DtEdttorGetMessageTextFieldlDISI Retneves the widget ID of the message 
text field in the DtEditor status line 

• DtEdrtDrGetSizeHimsO): Retrieves sizing information from a DtEditor 
widget 

• DtEditDrGoToUne(3|: Moves the insert cursor for a DtEditor widget to a 
specified Ime 

• DtEditorlnsertfS) Inserts data into a DtEditor widget 

• DtEditorlnsertFromFileO): InseHs data from a file into a DtEditor widget 

• DtEditofln^/okeRndChangeOialogO): Displays the DtEditor widget dialog 
for searching and replacing text 

• DtEditorlnvokeFarmatDialogO): Displavs the DtEditor widget dialog for 
choosing formatting options 

• DtEditDrlnvokeSpeliDialogO) Displays the DtEditor widget dialog for 
check iisg text for spelling errors 

• DtEdftorPasteFromClipboardO): Inserts the clipboard selection into a 
DtEditor v^idget 



• Dt£dttojflepl3cel3) Repla:es a portion of the contecrts of a DtEditor widget 

• [HEdftorf?eplaceFromFilef3r Replaces a porticm of the amtents of a 
Mdrtof widget with the contents of a file 

• DtEditorReseti3J Re^ts a QtEdiior widget 10 rts default state 

• DtEditorSaveConterjisToRlelSJ Saves the cootstts of a Dt£dftor wid^ to 
a file 

• Dt£ditorSelectAlf(3i Selects at! the text in a DtEditor widget 

• Dt£ditorSetC[jments(3i Pisces data into a Difdiiar widget 

• OtEdrtorSetCDnientsFromR!el3) Loads data fmm 3 file mto a DtEditor 
widget 

• Dt£clrtorSeilnsenionPosrtiant3l Sets the position Cff the insert cyrsuf in a 
DtEditor widge! 

• DtEdiiorTraverseToEdrtor|3) Sets keyboard traversal to the edit window 
of a DtEditor widget 

• DtEdttorUndoEdit^): Undos the last edit made to the text in a DtEditor 
Wfdgei 

ComboBoK Widget APIs, The DtComboBojc widget is a combination of a 

TextFJeld and a List widget that provides a list of valid choices for the 
TextFieid. Selecting an item from this list automatically fills in theTaxt- 
Re Id with that list item. _ _ _ _ 

• ^'inclode ^Dt/ComboBox,h> 

• DtConiiboBo5(i5) DtComhoBox widget defmitions 

• DtCreateCoTTiboBoxIS): Creates a DtCom bo Box widget 

• DtComboBoxOJ DtComhoBox widget clas^ 

• DtComboBoxAddEtem(3) Adds an item to the ComboSox widget 

• DiComboBoxDeletePos(3|: Deletes a DiComboBox item 

• DtComboBoxSelect[tem(3): Selects a DtComboSox item 

• DtComboBoxSetltemO): Sets an item in the DtCombaBox list. 

MenuButton Widgot APIs. The DtMenuButtan Widget is a command 

widget that provides the nienu cascading functionality of an XmCascade- 
Sutton widget, DtMenuButton can only be instantiated outside a menu 
pane. 

• ^include *^Dt/MenuBLitton.h> 

• OtMenuBiitton(5) DtMenuButton widget definitions 

• DtCreateMenuButtonl3): Creates a DtMenuButton widget 

• DtManuButton(31; DtMenuButton widget class 

SpinBox Widget APIs. The DtSpinBox widget is a user interface control 
for incrementing and decrementing an associated TextReSd. For example, 
rt can be used to cycle through the months of the year or days of the 

month. 

• #include<Dt/SpinBox.h> 

• DtSpinBox(5l DtSpinBox widget definitions 

• DtCreaieSpinBox{3} Creates a DtSptnBox widget 

• DtSpinBox(3): DtSpinBox widget clasS 

• DtSpinBoxAdditemO}: Adds an item to the DtSpinBox 

• DtSpinBoxDeiEiePos{3) Deletes a DtSpinBox item 

• DtSpinBoxSetltem(3|: Sets an item in the DtSpinBox Itst 

Calendar Library (tibcsa) 

Calendar APIs. The Calendar APIs include functions for inserting. 

deleting, and modifying entries, functions for browsing and finding 
entries, and functions for calendar administration. 

• #include <csa/csa.h> 

• cstcsa(5) Calendar and appointment services dehnitions 

• csa.,add_calendar(3): Adds a calendar to the calendar service 

• csa .add_entrv[3) Adds an entry to the specified calendar 
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• csa_calLcalJb3cks(3j; Forces ihe rnvocation of the callback functmns 
associaied with the specified callback lists 

• csa_delete_calendar(3l: Deletes a calendar from the calendar service 

• csa.,defete_entrv(3): Deletes an entrv from a calendar 

• csa JreeO) Frees memory allocated by [he calendar service 

• csa Jree_time_sesrch(3): Searches one or more calendars for available 
free time 

• csa_list_calendar_attributes(3}: Lists the names of the calendar attributes 
associated with a calendar 

• csa_lfst_c3lendars{3!: Lists the calendars supported by a calendar service 

• csa_li$t_entries(3}: Lists the calendar entries that match all the attribute 
search criteria 

• csa_fist_entry_attributes(3); Lists the names of tbe entry attributes 
associated with the specified entry 

• cs3_list_entry_sequence(3): Lists the recurring calendar entries that are 
associated with a calendar entry 

• csa_logoff{3)" Terminates a session with a calendar 

• csa_lo9on(3}" Logs on to the calendar service and establishes a session 
with a calendar 

• csa_look_up|3): Looks up calendar information 

• csa_query_cDnfigijratronf3): Detemiines information about the installed 
CSA configuration 

• c sa_ re a d_c a 1 en da r_attributes{3): Reads and retums the calendar attribute 
values for a calendar 

• csa_read_entry_attributes(3); Reads and returns the calendar entry 
attribute values for a specified calendar entry 

• csa_read_nB)ct^reminder(3): Reads the next reminder of the given type in 
the specified calendar relative to a given time 

• csa„register_callhacM3): Registers the callback functions to be invoked 
when the specified type of update occurs in the calendar 

• csa_resiDre(3): Restores calendar entries from an archive file 

• csa_savel3l: Saves calendar entries into an archive file 

■ csa_unregister_callbacM3): Unregi stars the specified callback functions 

• csa_update_calendar_attributes(3); Updates the calendar attributes 
values for a calendar 

• csa_update_entry_attributBs(3): Updates the calendar entry attributes 

• csa_x_prDcessjipdates{3); Invokes a calendar application's calendar 
event handler 

ToofTafk Messaging Library (libn) 

Too ITa Ik Messaging API. This API provides functions for managing all 

aspects of Too ITalk messaging. 

■ ^include <Tt/tt_c.h> 

• Tttt_c(5)' ToalTalk messaging definitions. 

TooJTalk Toofkit APIs, The ToolTalk toolkit APIs are a set of higher-level 

interfaces to the ToolTalk messaging APIs. The ToolTalk toolkit APIs facil- 
itate use of the desktop message set and the media exchange message 
set. 



• #[nclLide <Tt/tttk.h> 

• TttttMSI; ToolTalk toolkit definitions 

• ttdt„Git_Mi3difjed[3); Asks if any TonlTalk client has changes pending on 

a hie 

• ttdt„Revert(3): Requests a ToolTalk dient to revert a file 

• ttdt^SaveO): RequBSts a ToolTalk client to save a file 

• ttdt,:losef3|: Destroys a ToolTalk communication endpoint 

• ttdt_file_event|3): tJses ToolTalk to announce an event about a file 

• ttdt_fileJoinl3): Registers to observe ToofTalk events on a file 

• ttdt_file_naticE(3|: Creates and sends a standard ToolTalk notice about a 
file 

• ttdt_fjle_ciui!f3| Unregisters interest in ToolTalk events about a file 

• ttdtJi[e_reqL/est(3): Creates and sends a standard ToolTalk request about 
a file 

• ttdt_message_sccept!3); Accepts a contract to handle a ToolTalk request 

• ttdt_open(3): Creates a ToolTalk communication endpoint 

• ttdt_sendef_imprint_on(3}: Acts like a child of the specif iGd tool 

• ttdt_sessionjoinj3), Joins a ToolTalk session 

• ttdt_session_quit(3) Quits a ToolTalk session 

• ttdt_subcontract_managej3): Manages an outstanding request 

Motif Toolkit Libraries (libXm, EibMrnin ltt)Uil) 
Motif Widget API. The CDE Motif Widgei API (Xm) consists of the Motif 
1.2 widget library (libXm) with enhancements to existing functionality 
and bug fixes, The CDE Motif widget API maintains source compatibility 
and binary compatibility with Motif 1.2 applications. 

• linclude <Xm/XinAlLh> 

Motif Resource Manager API. The Motif resource manager API (Mrm) 
creates v^idgets based on dehnitions contained in user interface definition 
files created by the user interface language (UIL| compiler. The Motif 
resource manager interprets the output of the UIL compiler and generates 

the appropriate argument lists for widget creation functions. 

• #fnclude <Mrrn/MrmAppLh> 

• #includE <Mrm/MrrnDects.h> 

• lincfude <Mrm/MrmPublic.h> 

Motif User Interface Language (UIL| API. The Motif UIL is a sped- 
fication language for describing the initial user interface of a Motif 
application, 

• fin elude <uil/Uil.h> 

• #inclijde<uiE/UiiD8Def.h> 

• #inciude <uif/UilSyrnDet.h> 

• #include <uil/UilSymGLh> 

ToolTalk is a Ifadetnarlc of a regrsiefed trademark af Sun MicrasystEms, Inc. in Hie LI.S.A,3nd 
certam other countfies. 

Moiif is a trademaTJc at the Open Softwate Foundation in Uie U.S.A. and orher ctjuntries. 
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Accessing and Administering 
Applications in CDE 

Setting up transparent access to appiications and resources in a highly 
networked environment is made simpler by facilities that enable system 
administrators to integrate applications into the CDE desktop. 

by Anna Ellendman and Williani R. Yoder 



A m^or purpose of a graphical desktop is to make it easier 
f(jr usenf l<> browse ant) nm applications and to identify? iuid 
nuiiuj>ulare the applieaijt)ns' data files. Since t^NDC ' s.vstents 
ai'e generally highly networketl, it is desiral)le that a desktop 
also provide network transparency^ — the abUily to launeti 
applications an(i supply data to Tliem without wort^ ing 
about where in the network tlie applications and data are 
located. 

UTierever possible, these ease-of-use features should not be 
provided at the expease of system administrators. Tliere 
should t>e a standard t>r«K-ediire Tor incoiporatlng preexisting 
appliratiojis uU(j tlie desktop, and die tlesktop should provide 
tools for perfoniiing these proceed ures. 

This article riescribes how users locate and kuuich applica- 
tions from the ('DE tk*sklop and how system adnunistraiors 



integrate appijcalions Into the d^ktop's graphical environ- 
ment The infomialion is also rekn^ant for applk-ation devel- 
opers, since the administration nuidel imd tools for iniegrai- 
ing existing applications are also used to provide basic 
desktop integration for new apphcations. 

User Model f(ir Applications 

CDE makes it easier tor users to access and nm appiications 
by providing: 

• A way to represent an application as an icon. The user cait 
start an application by doubkMiic^king tlie icon. TItese icons 
me called applicaiiot^ rcoiis. 

• A specUil container lor application Icoils. This container is 
called tlie applicafion managei\ 

• A way to specify the unitjue appear^m(*e luid behavior for 
icons represeutiug an aji plication's data files. 
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Application Manager and Applicatiofi Icons. Ttie l^licatlon 
manager is a single container for all the aijplications avail- 
able to the user aiid is opened by t'lickini? a control in tlie 
CDR tr<int parwl (see Fig, 1 ). Each item iii the top level of 
the applirati<jii manager is a directory coniaining one or 
more related applications. These diieclories are called 
application groups. 

By convention t an applicat ion group contains, for each 
application in the group, the application icon that staits the 
application, plus other tiles rehitcd to die application such 
as sample data files, templates, and online in Ion nation (see 
Fig. 2). The system administrator can organize the applica- 
tion groups into deeper hierarchies. 

Since the application groups are displayed together in a 
single window, they appear to occupy the same file system 
location. Tliis makes applications easy to fmd and launch. 
The tact that this is not the case, and that the application 
gioups m'e actually located in a variety of local and remote 
locatioiis, is hidden from users. 

From the end users point of view, the apphcation manager 
window is owned by the .system. 'Hve user fJoes not have the 
ability to create or move icons in the window directly. 

Data Files and File Manager Like the apphcation manager, the 
file manager represents objects as icons. Frequently, tliese 
objects are the application data fdes. The desl<top provides 
a way to specify tlie behavior of various types of data files. 
This makes it possible for users to start, an applicat ion from 
I he file manager by double-clicking one of its data files, by 
dropping a data file oji tiie apijhcatioi\ ieoiu or l>y choosing 
Open from the data tile's pop-up Jiienu (see Fig. 3), 

Application Manager Administratioti 

The apphcation manager is designed to meet sever^il hupor- 
tant requirements; 

• It must ajjpear to l)e a single location into wJiich applications 
are gatJiered from a variety of locations. 

• ft must be customizable on a personal (per-user) or system- 
wide (pei-workstation) basis. 
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Fig, 2. ('ejnr.r^nts of an applicaUon group for a single application. 



It mnst l>e netw^ork capable, that is, it nm.st be able to gather 
appUrations loeated on other systems. 
It mnst be d>^lamie so that its contents cm\ be chi^iged 
wlion apphcations are added to or renioved tVom liie local 
system or application servers m the network. 

To meet these requirements^ the CDE designers chose to 
make the application manager a fUr manager \dew of a spe- 
cial temporaiy diiectory. The apphcation manager directory 
is created automaticaJly when the user logs in at the location: 

/ var / dt / appconf i g / appmanager / login-display 

For example, w^hen user anna logs into CDE at flLsplay 
hpcvxpae:0, the CDE login manager creates the directoiy: 

/ var / dt / appconf ig/ appmanager / anna - hpc vxpae - 
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Fig, 3. Runi'Ling m\ application u^hig (a) a data file's pop-u|:i inenLi in the file maiiager or (b) drag and drop between tlie file manager 

and the application manager. 
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The directory is both iiser and display dependent Each user 
gets an ^pliration manager diret'tory, and a user logging 
into more ilian one system obtains a separate application 
manager direcioiy on each system. This b ncK'essary to 
allow the application manager to be customized on both a 
f>er'User and a per-system ba^. 

The amplication manager direct0r>' persists for the length of 

the \mefs CDE session and is recreated each time the user 
logs in. The temporary' nature of the application manager is 
po^ible because none of its contents are actually located in 
Us fiJe sj-stem location. 

Gathermg Applications. After the login manager creates the 
application mimager tUrectory, it niirst gather application 
groups into Oie tlireclory. The application gniups iin^ gjithere<i 
by means of symbolit* links, and the links are made from 
multiple locations. This is what makes it possible for the 
apptfcation [uanager to display application groups located in 
a vaiif ry of directoiles. ittcluding personal, system-wide, 
and remote locations. 

The symbolic links thai garlitT Ihe ar>plk'ation groups are 
created by the CDE utility dtappgather, which is automatically 
run by the login manager each dme the user logs m. For 
exanitJle, the desktop provides a built-in application group: 

/ usr / dt / appconf xg/ appmanager /C / De sktop_Appa 
At login time* dtappgather creates the following symbolic link: 

/ var / dt / appconf ig/ appmanager /aiiaa-hpc vxpae- / 

Deaktop_Appa-> 
/uer/dt/appcanfig/ appmanager /C/DeBktop_Apps 

The result is that the application manager contains tlie 
Desktop_Apps application group (see Fig. 4). 

Application Search Path. To gather application groups from 
vaiious loratitjns, dtappgather requires a list of locations con- 
taining the ajiijliration grcmps to be gathered. This tist of 
locations is called the desktop's appUcation seiU'ch path. 
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The default application search path consists of three local 
locations: 

Personal S home / * dt / appc onf i g / appmanager 

System- wide / et c / d t / appcon fig/ appraanage r / $ LANG : - 
Built-in / u sr / d t / appconf ig / appmanag e r / $ LANG > 

Tlte built-in location is used for factor\'-installed appHcadon 
groups. S\^em adnnnistrators can add application groups to 
the sij^tem-wide location to make Utose applications av^ailable 
to aU users logging into the systeriL The personal location 
allows a user to add application groups tiiat are a\^able 
only to that single user. 

System administrators or users may need to add other loca- 
tions to the apphcation search path. CDE pro\1des two envi- 
ronment varijibles Uiat mcjdiJy' the application search path: 
the s>'stem-wide variable DTSPSYSAPPHOSTS and the personal 
variable DTSPUSERAPPHOSTS. 

The entire application search path, consisting of the default 
locations phis the atlditional locations specified by the envi- 
ronment vari ablets. Is created by a CDE utility named 
(ttsearchpath. The login manager runs the dtse arch path utility 
jus^ be fore if nms dtappgather. The dtsearchpath utility uses a 
set of niles to define how the total value of die search path 
is assembled. Directories Listed in the personal environment 
variable have precedence over the defauh personal location, 
and personal locations have precedence over system-wide 
locations. 

The most common reason for modi^ing the application 
search path Is to add remote locations on apijHcalion seners 
so that tiiose remote applications can be easily started by 
users. The apphcation search path variables accept a special 
syntax that makes it easy to add application servers. For 
example, VARfABLE-hostname; is expmuled l)y dtappgather 
(assuming NFS mcnints) U) the system- wide location on 
hostfiame: 

/net /<liostnaine>Vetc/dt /appconf ig/appmanager/ 
<$LANG> 

For exan^ple, if DTSPSYSAPPHOSTS specifies two remote 
systems: 

DTSPSYSAPPHOSTS=SystemA: , SystemB: 

and these systems contain the following applk^atlon groups: 

Sy 3 1 emA /etc/dt/ app c on f ig / appmanage r / C / 

Easy Accounting 
Sy B t emB / e t c / dt / app c onf ig / appmanage r / C / 
Be s t Spr e ads be e t 

then dtappgather creates Uie following symbolic Imks: 

/ var / dt / appc on f i g/ apymanage r / aim a ' 
hpcvxpae-O/EasyAccoyDting -> 
/net / SyetemA/ etc/ dt / appcon f ig / appmanage r/ C / 
E a syAc count 1 ng 

/ var / dt / appconf ig / appmanager / anna- 
hpcvxpae-0/BestSpreadSheet -> 
/ net / Sy atemB / et c / dt / appcon fig/ appinanager / C / 
Best Spreadsheet . 



Fig, 4. Tlie Deskmp_Apfis application group iis a buJIt in grrjup 
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Fig. 5. Till? application manager gathers application groups on tire application search path. 



If llie system uses a mount point otlier tltaii /ret, the system 
admiiiislrator can set a desktop enviroimient %^ariable 
DTMOUNTPQINT to specify^ the mouiit point location. 

Fig. 5 shows an application manager containing application 
groups gathere(i from personal, system-wide, ajifl built -iti 
locrations and from two application sei"\'ers. 

Application Infrastructure 

The ability to refiresem applications and data files as icons 
that have meaningful behavior and appearance on I lie desk- 
top is made possible by an infrastnicture of dei^kt tip t:*t:>n- 
structs and configLu-ation files. These constructs are actions, 
data types, and icon image fdes. 

Actions. The desktop uses actions to create a relationship 
between an icon in the application manager (or tile manager) 
and a connnand. Actions arc tlic constructs thai allow you 
to create application icons (icons that the user can doubie- 
elick to nin applications}. 

For example, consider the following defmition for an ariiori 
nanrcd Xwud: 



ACTION Xwud 

i 

LABEL 

ICOM 

ARG_TYPE 

WIMDOW_TYPE 

DESCRIPTION 



EXEC STRING 



Xwd_Display 
Xwudlcon 
XWD 

NO_STDIO 

Displays an X Windows BcreenN 
file 
xwud -in %Arg_l"XWD file:"^ 



> 



The desktop assembles and maintains a database of action 
defiiiitions, including built-in actions and odiers created by 
users and system admitiistrators. Once an action is defined 
in the actions database, it can be \isuiilly represented in the 
application manager or file manager as an icon. Tliis icon is 



called an application icon i)ecause the mKlcrlying action 
usually is \\Titten to lamicli an application. Since icons in the 
file manager and the apphcation manager represent flleSj 
creating an application icon involves creating a fik^ Ihat is 
related to the action. The relationsiup is providetl by giving 
the file the same name as the action (in this case, Xwudj^ and 
by milking tiie file executable. The real content of the file is 
irrclevartl. Fig. t} shows an application icon for I be Xwud 
actio ru 

The ICON and LABEL fields in the kwud action defirution de- 
scribe the appearance — the icon image useti and tiie text 
label for that Icon. The DESCRIPTION and EXEC_STRIN6 fields 
tlescribe the icon's l>ebavioj; live DESCRIPTION field contains 
die text dis]ilayed in the CT)E help \iewer when the user 
selects the icon and requests help (Fl). The EXEC_STRING 
specifies the conunaiid that Is nin wlien the user double- 
clicks the icon. For the Xwud action, the command is: 

xwud -in <file> 
where file is the file argument. 
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Th^ EXEC„STR!NG field uses a special svntax to represent file 
arguments. For example* the file argument in the Xwud 
action is repri^ented as: 

Tliis ^Titas speciSes how the application icon treats data 
files, Jf the user drops a data file on the icon laJjeled 
Xwd_P3spltv. its path name, supplied hy the desktop drag and 
drop infrastructtire, is used as the argument. If the user 
douhlc-clicks the iron, the action prompts for that path by 
displaying a dialog box with a text field labeled XWD Hleu 
which mdicates that user must enter the file nante of an 
X Window dump ( ,xwd) file. 

The ARG_TYPE field limits the action to a partioular type of 
data If the user tries to use a different type of file, either by 
dropping the file on the action icon or responding to the 
prompt, the action returns an error dialog box. 

Data Types. Files and directories are represented in the CDE 
nie manager as icons that users can manipulate, Tltere is 
Little advantage to Liiis iconic representation unless the 
desktop can supply meaningful af>pearaiice arid behavior ro 
these icons. Data typing provides this capability. 

For exantple^ directones ai>i>ear in the file nianager as folder- 
like icons, tUitl users f)pen a view of a directory by double- 
clirktag its icon. That l^ehavior, vvliich is unique to directories, 
is provided by data typing. 

The most common use for data typing is to provide a con- 
nection between data files and tjieir applications, K an appli- 
cation reads and wTites a special type of data, it is useful lo 
create a data ty]w for the data fik^. This data tyi^c might 
specify that the data files use a special icon image and that 
doubleHTlicking a rlata file inns the applic"ati«>n mul loads the 
data file. 

A data tyije deOnilion has two pads: 

DATA.CfllTERIA; specifies the criteria used to jLssij^n a file to 

til a I data tyjie. 

DATA. .ATTRIBUTES: defines a file's appearant:e and behavior. 

For example, here is a data tyjje dcfmition For X Window 
dump files (the data files for the Xwud aclion}: 

DATA_CRITEHIA XWDl 
( 

DATA_ ATTRIBUTES. NAME XWD 

MODE f 

NAME PATTEBM ♦.xwd 



DATA_ATTRIBtJTES XWD 
C 

ACTIONS Open , P r i n t 
ICON Dtxwd 

DESCEIPTIOJT This file contains \ 
an XWD graphic image. 
} 

The criteria definition specifies that the data type applies to 
files (MODE I) whose names ( NAME.PAHERN) end with the 
suffix .xwd. (CDE also supports content-based data typing, ) 

The ACTIONS field In the attributes dellnition descnbes the 
file's behavior. Tlie firsi enliy (in thisciise, OperiJ describes 
the fde s double-cliik btiuu ior. All the entries iJi the ACTIONS 
list aLs43 appear in the file mmiagei SeJEcted mentj (.see l^lg. 7|. 



In the desktop. Open and Print are general action names that 

are used mih many iisaa types. For xwd files, the Open action 
is a s>Ticm>^i for the Xwud action, and Uie desktop must pro- 
\ide a connection beti^'een them. Tliis connection Ls made 
through another action definition in which an action named 
Open is niapped to the Xwud action for the xwd data r>pe: 

ACTION open 

C 

TYPE MAP 

MAP .ACTION Xwud 

DATA. TYPE XWD 

> 

V^lien a user selects A data file in the file manager and nms 
the Open aclion on it (by doubltM* licking the fde or by 
choosing Open from the lelected menu ). the desktop searches 
for the ap]jropriaie Open aclion for that data type. Since this 
action is mai.>ped to the Xwud action, Uie desktop then nms 
the Xwud action, and passes the selected data file to it as the 
file argument. 

The Print action is handled similarly to Open. The following 
declaration is a set of actions for printing .xwd files: 

ACTION Print 



{ 



} 



TYPE 

MAP ACTION 

DATA TYPE 



MAP 

XWD_Print 
KWD 



ACTION XWD_Print 
{ 

ARG_TYPE XWD 

EXEC_STIIING /bin/ all -c 'cat %(P±le)Arg_l% \ 
jxwd2Bh Ipcltrans -a -R -e2 > \ 

SHOME/temp.pcl; \ 

dtaction PrintRaw SHOME/tejnp.pcl ; \ 
nn $ HOME /temp. pel ' 
( 
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Tlie XWD_Print action illustrates two additional features of 
aclinns: 

• All action can m\'okc a shell fbjn/sh in this case) 

• An action can invoke another action. This is done using tlie 
dtaction command. Tlie XWD_Print command changes the .xwd 
flic to a PCL file and dien invokes a built-in action named 
print Raw whirix prints PCL files. 

The article on i)a^c 24 ilcj^cribes the different t>7>es of data 
structures and daUiba^es asyociated widi CDE action and 
data types. 

Icon Image Files. Since the desktop makes heavy use of icons 
lu represent Hies, directories, and applications, icon image 
tiles are aJ! iniportiuu paj1 of the suite uf deskujp tonngura- 
tion files, 

A particuliu" object on the desktop generally requires several 
icons. For example, the file manager has \iewing prefer- 
ences for representing files as large icons (32 by 32 pixels) 
or smaU icons ( 16 by 16 pixels). Furthemiore, the desktop 
uses yjLxmaps for color displays and bitmaps for niono- 
cluTjme displays. To chfferentiate icons by size and type (pix- 
inap or bitmap), icon files use tiie naming convention base- 
name. size. type. For example, a large pixmap for tJie Xwud 
action might be named Xwudj.pm. 

Tlie icon image used by an objeel is specified in its action or 
data tyj>e definitions by the ICON fiekl {see examples above), 
wliich specifies tiie icon image ttj use m the file n^anager and 
tlie application manager. The ICON field specifies only the 
base name, and the desktop adds the appropriate file name 
extensions, depending on the file manager \'iew setting and 
type of display. FmiJiermore, tlic ICON field does no! specify 
a path. The desktop uses search paths to locate icons and 
other parts of tlie ilesktop infrtistnicture. 

Locating Actions and Icons. As with application groups, the 
desktop uses search patlis to locate action and data type 
definitions iuid icon files. Each apph cation search path loca- 
tion has a sel of coiresponding locations for actions, data 
types, and icons. For exajuple, Fig. 8 slu>ws t tie default 
system- wide search path locations. The types directory for 
actions and data t>pes and the Icons directoiy for icon image 
files are analogoiLS to the appmanager diiectory for the apph- 
cation groups. 

The help directorj,^ is used for application help files created 
using the CDE Help Developer's Kit. CDE help is described 
on page 38. 
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Tlie search paths for action, data type, icon, and help files 
aiT auloiiiatically updated when the application search path 
is modified, TliLs ensures that the desktop v^'ill find id\ tlie 
desktop configuration files needed by the application. 

For example. If SystemA: is added lo the application search 
path, the locations: 

Anet/SystemA/ etc /dt /appconf ig/types / < SLAHG> 
/net / ByB t emA / et c / dt / appconf ig / icons / < $IiAHG> 
/net/SystemA/etc/dt/aippconf ig/help/<$liANG> 

are automatically abided to the acdon/data ty\ie, icon^ and 
help search patliSn 

Create Action 

The syntax of action and data-type tlefinitionjs provides a 
great deal of flexibility in specifjiug desktop behavior. Wliile 
this makes the definitions veiy powerful, it also makes the 
syntax somewhat complex- 

TIic de skt op h u '1 u des m i ? i p p 1 i cat i on , rrfa tf ar t i on , that 
allows users and system achTiinistrators to create typical 
actions and data types witliout having to learn tlie syntax 
nUcs for the defuutions. C 'reate action provides fill-in-the- 
blank text fields lor supplying various paits of the action 
anti (lata type definitions and provides a way to browse and 
choose from available icons (see Fig. 9). Furthermore, 
create action allows the user to enter the conunand to be 
execnted (EXEC.STRING ) using shell language for fde argu- 
ments (e.g.. $n rather than %(Rle|Arg_r%). 

Create action is optimized for creating actions and data types 
for applicalions. l! creates an action to launch the apphcation 
and one or tnore data types for Uie apphcation. For each data 
type J create action produces an Open command that nu^ the 
application. Optionally, it can also create a Print action. 

Application Integration 

An application can be JiTtegratefl into the desktop by placing 
its desktop configuration fdes into the locations specified by 
the flesktop search paths sho's^n m Fig. 8. However, this can 
make administration difficuH: because the fUcs tue scattered 
among nmuerous dii-ectories, each of which contains files 
for many applications. 

It is usually preferable to gather all tiie configiuation files 
for an application in one location, called the apphcation root 
( 3pp_root). Apphcatlons generally me installed this w^ay. For 
example J the files for an audio application might be insttdled 
under /opt/audio. However^ since the directories under the 
app_roGt are not on the desktop search paths, the application 
groups, actions, data t>ijes* and icons wimld not be found 
uidess the search patiis were modlfietl 

Application Registration. CDE provides the utilit:^' dtappintegrate 
which lets s^^stem adnunistrators install desktop-related 
application files under an app_root directory without tnodily- 
ing tiie desklop searcli paths. The function of dtappintegrate is 
to create links between I he deskloj) files in the app^root kjca- 
tion and the system-wide search patii locations. The process 
of creating tiiese links with dtappintegrate is called application 
registration. 
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The collection of desktop configuratioii files beneath the 
spp_foot directoiT^^ is called the it^gLstratioii package. Fi^- 1*^ 
illustrates a registration package for an application named 
BestSpreadSheet. 

The registration package contains the desktop configuration 
files needed by the application, including the application 
group, actions, data types, icons, and iielp tiles. The registra- 
tion package uses the same flirectoiy organization as the 
seaich patlis (compare Fig. 10 with Fig. 8). 



Once tlie regisitration package has been created, the regis- 
tration is accomplished Uy running the dtappintegrate utility, 
which creates the symbolic Ihiks shown in Fig. 1 L 

The system administrator can also use dtappintegrate to break 
the symbolic links for an application's desktop configuration 
tiles. This is necessary to n)ove ait application to a different 
apphcation sei-ven In addit ion, die system administrator can 
also use dtappintegrate (o move the apphcation <■ on figuration 
registry- to a different location on the application ser\^er to 
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Application Servers and Clients in CDE 



CDE operates in a networked, client/server erviranment. This article 
describes the services and configuration files provided in CDE to support 
client/server remote execution. 

CDE Networking Services 

Tiie CDE networking model fncEudesfourpnmary services: 

• Desktop display services. These services consist of the XI 1 display 
server, keyboard and pointing devices, and limited auxiliary processing, 
such as window management and audio services. 

• Session services. Session servers provide login and authentication, 
session managemeni, and desktop services spch as file manager, style 
manager, and action invocation. 

• Application services. Appiication servers provide both terrrtinal and 
GUI-based applications. When an application is located and running on 
a system other than the session server, it is said to be a remote applica- 
tion, and the system running the application is the application server 

• Fife services. File servers store the data that applications produce and 
manipulate. 

The primary way that application servers, file servers, and session serv- 
ers share data in CDE 1.0 is through the remote file system IRFS) mecha- 
nisms, as offered by the DCE Distributed File Service I DPS) J the Andrew 
File System (AFSl, and the Network File System (NFS), 

There may be other system services available in the distributed desktop 
environment, such as font, printing, and fax servers. 

Remote Application Models 

The desktop can access a remote application by RFS-based execution or 
by remote application execution. 

• RFS-based execution. In this configuration, the application binaries 
reside on the remote system but are run on the session server From the 
session server's point of view, the remote system is simply a big disk 
attached to the workstation by means of RFS. The remote system Is not 
a true CDE application server because it is not providing application 
execution services. 

• Remote application execution. In this configuration, the application 
runs on the application server and displays its output on the user's desk- 
top display. This configuration requires the linkages shown in Fig. 1. An 
advantage of this configuration is that the application server can he a 
different machine type or operating system version than the session 
server. This is common in today's heterogeneous environments. 

CDE provides a small subprocess controi daemon (dtspcdl that is 
installed on application servers. The subprocess control daemon receives 
requests from CDE components (such as the application manager) to 
launch processes on the application server on behalf of the user. 
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Fig. 1. Linkages for remote application execution. 

Configuring a CDE Application Server 

Typically, a COE application server contains the application binaries, 
application configuration files (such as app-deiauEts and message cata- 
logs), and the application's CDE desktop configuration files (application 
group, action and data type definition files, icon image fiies. and help 
fiJes), Locating all the application s configuration files on one system 
makes the application easier to install and admin isier. During or after 
installation, the dtappintegrate utility is run to link the configuration files 
to a location where clients expect to (ind them. In addition, the subpro- 
cess control daemon must be configured, and clients must have permis- 
sion to access files by RFS. 

Configuring e CDE Application Client 

A system accessing a CDE application server must add the application 
server to its application search path. This is done by setting a system- 
wide or personal environment variable. For example, the following line in 
the fife/usr/dt/config/Xsession.d/OOIO.dtpaths adds an apphcation server 
named System A to the client's appliqati.on search path; EJTSPSVSAP- 
PHOSTS=SystemA:. 

In addition, the diem must have RFS access to the application server 

Furthermore, a client must be configured to provide X authorization for 
the application server to access the clients display, The easiest way to 
set up authorization is to configure the user's home directory so that it is 
available to all application servers. This configuration is called a net- 
worked home directory. 

Reference 

1 . M. Kong, "DCE: An Environment for Secure Client/Sewer Computrng/' Hewlett- 
Packard Journal \/qL46. m. 5. December 1395, pp. 6-2Z, 



control which users can access an application from the 
(lesktop. 

Regathering Applications. Applications registered by dtappirte- 
grate do not lieconve available from tlie application manager 
until the utility that gathers applications from seiircli path 
locations^ dtappgather, is reintn. Since dtappgather nni;^ automat- 
ically at login timCi newly registered appli rations become 
available when the user logs out and back in again. To save 
users the inconvenience of logging out, the desktop provides 
an action named Reload Applications, The user can nm tliis 



action by opening the application manager and double- 
clickiiig the Reload Applications icon. 

Conclusion 

CTtE provides tiie abiUty to represent applications and their 
data iiles as icons, and supplies a single cojitainer for appli- 
cations caUecl the a[jp 1 1 cation manager. Applications are 
gathered mto the application manager fion> multipJe loca- 
tions specified by the apphcation sesirch path. Remote loca- 
tions can be added to the application search path so Ihat 
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apjilkarions on netw^orkr-d applitai ion sen-el's can be inte- 
grated seanilessily inio the ai>pUf 'atioti maiiagen Tlie infra- 
stnirture rc^quired to represent ap|j lie ^it ions as icons (Consists 
of actions, tlata i>i>es, and icon image files. Tliese files can 
be placed into a registration package for the application and 
then registered onto iJie desktop using the dtspp integrate utiiity. 
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The CDE Action and Data Taping 
Services 



Several different types of databases and their associated APIs are 
involved in determining the look and behavior of icons presented in the 
Common Desl<top Environment. 

by Arthur R Barstow 



Tvvo fundamenlal requirements of a computerized desktop 
system are a unified \iew of a users data aiid a ronsistent 
access metJiod ItJ die tlaUi, Tliis ailicle desciibes how 
Hewlett-Packard's Common Desktop Emiroiiment (CDE) 
meets tliese requiremenLs through Uie use of jLs dala (yi^itig 
mid action services. Tlte data t>i>ing sendcp defines atnitxites 
of a data tyyte sucli as \is appemmire (icon) and heliavior 
(action). Tlie action service provides mechanisms for luikii^g 
a data type s beiiavior to its associated application or exeru- 
tion command. 

The data tyiiing service and the action service hoth use data- 
bases. Tlie data typing service database contains data criteria 
and data attribute records, tmd the action senice database 
contains action records. "Hie lemi database in tire context of 
data ty^jing and action databases refers to records stored in 
flat, ASCII files and not in a generalized database service. 

Applicalious wanting to use these CDE services must first 
load the flatai>aseM into I he applications memor^^ Once 
loadefl, aj)];)Ii€ation iirograinnwig interfaces (APIs) destTli>efi 
in this aiticle cmi be used to access the database. CDE only 
pro\ides APIs to retrieve data from the databases. 

Each database record consists of the record type name, the 
name of the rect>rdt ;md one or more attiibutes (also called 
fields). Each attribute has a name and a value and each 
attribute must begin on a separate line. Fig. 1 shows Ore 
basic elements of a database record. 

Although CDE defines numerous datatypes and actions in 
it3 default databases, Oiese databases can be augmented 
with system-wide and user-defined records. Cser-defified 
definitions have the liigli est precedence, folio vtTd by sys- 
temwide ciefinitioas. The default databases have the lowest 
precedence. 
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Rg. 2 shows an overview of the CDE data typing and action 
serv ices and and I heir intenelatiotiships. These data struc- 
tures and their relationships are described in this article. 

The Data Typing Service 

As mentioned above, tlie data typing serxlce contains data 
criteria and data attribute records. Data criteria recorcis 
contain rules for recognizjiig a data tyt>e. Tlie niles may 
specify a data ty]3e s file name extension or file perrtiissions. 
Data attriliutc records are used to define a (lata tyi>e's 
ap]jeiu'ance ^uid beha\ ior such as a type's icon and associated 
applications. A data type cmi be defined for a file or a buffer 
of ntemuTy. 

Data Crilerla Records, Data criteria records defme the rules 
for recognizing or identifying a data type l>y using the 
following critei'ia: 

• File name (including shell pattertY matching symbols} 

• Contents (may be a file or memory buffer) 

• File pemiissions and file type (a file ty]>e may be a directoryt 
synilmlie link, etc.). 

The following declaration contains three data ciiteria 
records for an image viewer apjjlicat ion t hat can display 
files and data in fonriats such as XII bitmaps, GIF images, 
and XI 1 pixiTiaps. 

DATA GEITERIA ImageYiewl 
t 

DATA__ATTRIBUTE_NAME Image 
MODE f&w 

NAME_PATTERN * , g i f 
} 

DATA_CRITERIA ImageViewS 



{ 



} 



DATA .ATTRIBUTE NAKE Image 

PATH_PATTERN * /bi tmaps / * , bm 



Fig, 1* The basic stmcture of records contaiiied in the CDE data 
typing and actieii databases. 



DATA CRITERIA ImageViewB 

t 

DATA_ATTRIBUTE_NAME Image 

CONTENT string tdefine 

} 

All of these records refer to the data type Image. The Image- 
View! record will match any \\Titable file witb a file name 
ejaejision of , git. The JmageView2 record will match any fOe 
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E>>ta Typinf 
Service 



• Oefmes Rules Idr IlKOfstizmf 

• RecogiritiQa Cmerta: 

— FikHftttt 

— hteExtonioKS 

— PeimbsioH 

• bnfc: 



« Message -fiased 
Acliorts(SeEid ftiid 
ne&0Jv« ProtocoM 



« Command Um to 

Execttle 
• Hcrst Midline isa 



OauAitrttMaftecord 

* DefioesJ^i|mmce 
(Icons) and Selitfvior 
CAdtDnsi 



-i 



M^p Aciion 

* Njime qI Data 
AUiifaifte Reford 

• Uaam ot fksuotx lo 
Be ImlirectlY 
Invoiced (e.f., f^inll 



Action Service 



Fig, 2* All ovemew of tfie rc^ia- 
ami aciitin serviL'c? data smicures. 



t^mliiig in bm, hut the Ilk' niiLst bv in a directory namect bit- 
tnaps. The tmageViewS ret ore! will iiTatcli any file containing 
the suing ^define m ihe beginning of ihe file. Pig. :3 contains a 
pseu(tf»-FiNF (Backns-Navier fonn) for a data crileiia recfird 

Data Attribute Records. Data attribute records defme a data 
l>l>c's iiiuiie as well as other attiibuf es of the data type such 
jis it.s icon m\d application binding. Tlie data Iji>c nante iy 
the same as the data aUrihiite record name. The foOowdiig 
(teclaration shows the data attribute record for the Image 
data atlrjbiite <lenne<i in tit e tiata criteria re<;ords at>ove. 
A data atinbiire recoiti am Ire associated wiiii an unlinilted 
nunilior of data {riteria recor(is. 

DATA ATTRIBUTE IinaLge 
{ 



ACTIONS 
ICON 

ldIME_TYPE 
PROPERTIES 
MEDIA 
DESCRIPTION 



Open, Print 
imagedata 
image /j peg 

visible 

Image Data 

Data type for the 

Image viewer application 



> 



This data tyi>e s ieon is imagedata. Applications such as the 
CDE file ninnager will use fhis icf>n to rejrresent image tlii^?!*. 
For exinnple> if tjie file tniuuiger fiiuls a (lie naineil kJte.gii the 
file will be represented with the imagedata icon. This data 
tj^pe ^dso defines alt ribofes I hat may be of interest to <:itlier 
da!a-tytjing-aw;m* a]>[)liraii4>ns. For example, a mjiilej- api>li- 
carion may use the value of t lu^ MIME^17PE attjibnte to decide 
how an attachment sliould be \1ewefl, 

D£itB attribute rec^ords are the only reef>ril \y\n^ that can con- 
tain ap pile all on-specific fields — tliey are not limited to a 
fixed set of Held names. Fig. 1 shows a pseudtJ-BNF fur data 
aitrilnite records. 

Data Typing Service APIs. Before the data typing APIs can be 
iisfd, aji appliraljuii miiM first load ibe databa.ses t>y culling 
the DiDbLoad fimctiiai. Mter this, iin application .should Jegis- 
ler a database nu^dilkation callback nuuiion using the 
OtDbReioadNotifv funetitin. Tliis callback will be invokcfl wlu^n 
a user in\ okes tlie a<linii Re load Actions to Uiifify dala!y[)ifig- 
awiU'e atJplieations that a data tyt>e or acticjti record lias 
been adrlcti. niodiileMi, av rleU^ied. If ;ui ai>plicatit)n fails to 



register the modification ctiDback. it will not be notified of a 
databiise change, resulting in the application having an out- 
dated database in memoiy and possilily apiiearing and behav- 
ing differently tiiaji applit ations dial re<'eived the noMfication. 

Tiie first consideration m choosmg the APF to retrieve infor- 
mation from the data t>pe database is whether the applica- 
tion already has a data type n^inie for an tjbject or if the ol>~ 
ject of interest is a file or a pointer to a niemcu^- buffer. For 
exanit>le, if an application wants lo determine the icon asso- 
ciated with the filetanager.gif, it would fii^il make (bt^ hiUowijig 
call: 

char *dflta type name - DtDtsFileToDataType 
( " t anage r . gi f " ) 

to deteniiine the data type name of rhe file. To retrieve the 
ieon for this data type, the application would then call: 

char *ic;on name = 

DtDt sda.t atypeToAt t r ibuteValue 

( d a t a_ t ype _name , 

"ICON", 

NULL) 

For the data criteria and data attribute^ lecords given ai>ove, 
these two setiiienees of calls would resnit in stiiing 
tcon_name to imagedata. 

The tiext consideration is whether the desired information is 
a specific attriljute of a dat-a type or a (NULL-tennirvafed) list 
of all attribute name iind value pairs (or a data type. The 
ffillowing function retrieves all of ti>e attribttles for a ntt*tn(jiy 
bufh^r: 

DtDtsAttritJuts **attribT.ites = 

DtDt s Buf f erToAt t ribut eL i St 
fvoid *buffer^ 
int buffer lengthy 
NULL) 

For perlbrmance reasons, if an appli<'ation needs more than 
one attribute for a data tyi>e, tJie APIs to retrieve till attributes 
with a single call should be used. 

The Action Serviee 

hi C IfE, the action Venice tu<.t\idi^s the intVastiiRliue loi 
consistent data access througli polymoiphlc action nannug. 
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DataCriteriaDefn 



' DATA_CRITBRIA ' blanks record name 



data_criteria_defii 



'>' 



data_ciriterla defn : :=; { 

' FATfi_P ATTERN ' blanks pattern_dataa newline 
\ ' NAltE_PATTERN ' blanks pattern (3 at as newline 
I 'LINK^PATH' blanks patterii_datas newline 
i 'LINK„NM1E' blanks pattern_datas newline 
I 'CONTENT^ blanks content fields newline 
I ^MODE' blanks mDde_specB newline 
I 'DATA_ATTBIBUTES_NAMB' blanks name newline 
) 

pattern, da tae 

p at t e rn „da ta 

pattern 

defined in sh( 1) 

mjOde_Hpe c s 

inode_epec 



pattern data [ ( '& ' ( ' 1 ' ) pattern., dates] 
[/ i '] pattern 
a shell pattern matching expression* as 

:^ mode_spec [('£' | M') mode_speCHj 

1= i 



I 



type spec fpemiiHHion_spec] 
type, spec {'&* I M^J perm±seion_spec 



) 



type_spec 
type char 
permiasion spec 
penniasion., char 
eontsnt_f ields 
content field 



[ 

f'd' 
[ ' ! ' J 



I 



offset blanks 

offset blanks 
offset blanks 
offset blanks 
offset blanks 



] type_char {type char} 

I '1' I 'f I 's' I 'b^ I 'c' ) 
permission char {pennission_char} 

■- content_field {{'&' \ 'I') conteiit_ fields] 

'■ i 

' string ' blank s string 
'byte' blanks data_values 

' short '■ blanks data_values 
'long' blanks da ta_ values 
'filename' blanks string 



offset 

da ta_ values 

data value 

0) or hexadecimal 
name 

nsaie , char 
String 
newline 
blanks 



::- an unsigned decimal integer 

11= data_value [blanks data values] 

j:= an unsigned integer: decimal, octal (leading 
(leading Ox or DX) 

= { "A-2j" I '^a^-z'^ ) [naiiie_char] 

= { "A-Z" I "a-z" I "0"9>' I "-" } 

= a cha.racter string, not including <newline> 

= one or more <blank>s {spaces and/or tabs) 



Fig. 3. The pseiida-BNF for a data 
critfiria reeord. 



De.sktop components, such as the C!1E file manager and the 
CDE mailen use the action sei'vice lo start on application 
with a user's flaUi. ^\Tien a user opens a dMlii file in the file 
manager^ Lite action service opeas the appJication associated 
with tJie data type* For example, when a mail folder is 
dropped on ihe nudl control in the CDE front piinel. the 
action senice is used to open a mail instance with the 
dropped folder. 



The following action types are provided in the action 
senice: 

• Map aclions, which provide consistent action naming 

• Connnand actions, which encapsulate <^omniand lines 

• Message actions, which use the CDE message senice to 
encapsulate a request or notification message. 



DataAttr ibutesDe f n 



' DATA_AT!rRiBUTBS ' blanks record_nam6 
data a-ttributee defn 



data_attribntes defn 



string 
newline 
unique string 

blajiks 



:^ ( 

'DESCRIPTION' blanks string newline 
I 'ICON' blanks string newline 

'INSTANCE ICON' blanks string newline 

■PHOPERTIEE' blanks string {',' string} Qewline 

'ACTIONS' blanks name {'^' name} newline 

' NAME_ TEMPLATE ' blanks String newline 

' IS _ EXECUTABLE' blanks string newline 

'MOVE_T0 ACTION' blanks string newline 

' CO PY_TO_ ACTION' blanks string newline 

'LINK TC^ACTION' blanks string newline 

'IS_TEXT' blanks string newline 

'MEDIA' blanks string newline 

'MIME_TYPE' blanks string newline 

'X400_TYPE' blanks string newline 

unicjiie_string blanks string newline 

'#' string newline 

) 

a character string, not including <newline> 

'\n' 

a uniquely named string for implementation 
extensions 

one or more ■cblank>9 (spaces and/ or tabs) 



Fig, 4. Tlie pseudo-BNF for a data 
attribtite record. 
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Map Actions. Map actions pro\ide a mechsnisin to present 

acliuii naiiief* consiste'nily, regardless of data \yiy&^ CDE pro- 
\ides nimierous data tjpes and each tjpe has an associated 
open action (an open action ustiaily starts the ^^'s applica- 
tion). To get consistent naming, the open action for each 
daia tjpe is named Open and eacli data ij^e's print action is 
nanted Print Tills allows applications such as the file manager 
to include in a data file's list of actions the names Open and 
Print, regardJess of the actual action used to open or print the 
data type. The foUouIng are examples of map actions. 

AetlOH Open 



raothra^x-org 



# Freseotation attrilmtes: 



{ 



} 



TYPE MAP 

AJtG_TYPE linage 

MAI*_ACTION Open_Image 



ACTION Print 
{ 

TYPE MAP 

AEG_TYPE Image 

MAP_ACTION Print Image 
} 

ACTION Open 
{ 

TYPE MAP 

ARG_TYPE Gif 

MAP. ACTION Open Gif 
} 

The TYPE attribute is MAP for map-type actions. The AfiG_TYPE 
attribute gives tlie name of the associated (lata attributes 
record. The MAP.ACTJOrJ attribute gives the lumie of the 
action that will be indirectly invoked when the Open action is 
invoked. 

Th^ first Open aJid Print defuiitions aiv map actions for the 
Image datatype defined in the Image data attribute record 
given allr>v^;^ Daia altrihuff rec<jrfls imx] action records are 
hnkecl by ;^ui actions ARG_TYPE lii^kf If an application invokes 
an open action on an Image tiata type, the resulting action 
that gets uwoked is QpBn_lmage. 

The second Open definition is another open aition biit for 
GIF-type files. When tiata of this t.ype i.s opened, 1-he Open_Gif 
action is indirectly invoked. Overloading inai> actioji najnes 
makes it possible to present the user wilb ttjnsislejii anion 
names. 

Command Actions. Command actions are used to encapsulate 
iiibitrary rummimd lines (e.g., l^NIX* commands and shell 
scripts) and application execution strings. Comnimid actions, 
identified with a HPE fieJd of COMMAWD. have three types of 
attritaites: invocation, signature, i:Uir.l jiresenlatjon. The fol- 
lowing declaration shows these tliret^ types with a comn\and 
action flelinidon for the Openjmage action. 

ACT I ON ope n_ Ima ge 

{ 
# Invocation attributes: 



TYPE 

EXEC_ STRING 



WIKDOW^^PYPE 
EXEC HOST 



COMMAND 

/opt/imageviewei'V 
bin/ image viewer \ 
%Arg„l% 
NO_STDIO 
^DatabaseHost^, \ 



ICON 

LABEL 

DESCHIPTIOH 



linage app 
Image Viewe 
Invokes the linage- \ 
viewer applicationX 
for Image data types 



# Signature attributes: 
ARG_TYPE Image 
ARG CQUHT * 
AKG_ CLASS * 
} 

The invocation attributes define an action's execution 
parameters. Tlie EXEC_STfl3NG attribute contiiins the action's 
command line. The command line may contain ke^'words 
(e*g., %Arg_1%) which are replaced when an action is invoke^l 

The* WINDOW^TYPE attribute specifies the window support 
required by the action. In this example, the image \iewer 
application creates its o^n ^dndow^ so its WINDOW_TYPE is 
MO_STDI0. Other ^vii^dow t^pes are available for commands 
neetiing t ermhial emulation support. 

The EXEC_HOST attribute Ls used to speciiy a list of potential 
hosts on which the command could be executed. A keyword 
can be iiserl to refer to a host name genericaily rather than 
exj>licitiy naming a host. For example, the kcj'word %Data- 
baseHQst% refers to the host on which tJie action is deffjied. 
Mien a List of hosis is used, the comrnanti will only be exe- 
cuted once, on the first liost on which the comnuuid exists. 

The presentation attributes (all are optional) are fCON, LABEL^ 
aiul DESCRIPTfON. Applications like the file manager use the 
ICON attriljute to determine tlie icon \a use to represent, aii 
action. The tAQEt attribute defmes a (i)olent iaily localized) 
uFer-visible name for im action. The DESCRIPTiON attribute 
contains a short description of the action. An application 
should display the descriplion as a result of a user's request 
for specific information aliout an act it m. 

The signature attributes ARG^TYPE. ARG_COUI^T and ARG_CLASS 
(leririe the arguments accepted by an action. ARG_TVPE speci- 
lies a list of the data ty|je names an action accepts. The data 
type names refer to data attribute record uiunes. The ABG_ 
COUtsIT at tribute specifies the nmnber of arguments an action 
cicrepis. The ARG^CLASS attribute specifies tlie chiss of argu- 
mejnts the action accepts, such as files or memoiy buffers, 

\^Tten an application invf jkes an action, it gives the action 
service an action nanu' iuid data argtiments. TJie action ser- 
vice fii-st searches tlie aciif>n database lor actions matching 
the action name. Next the at1it)n rercjrd Ihat matches the 
acdon name is cliecked frjr a nialtii bi^i ween the action 
record's signature attributes and tJie data argimients. If a 
match is found, the associated action will be invoked, other- 
wise an error is retunicd to the apphcation. 

Message Actions riie CDE message service provides the 
ability For applJcaiions to send and receive messages. The 
action service in turn ] provides the ability to encapsniate a 
message. A rnessage-tyi>e action is speci^ed by setting the 
TYPE attribtite to TT_MSG, The following is an exaniiJle of a 
message-type action. 
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ACT I on OpenDirectoryView 



I)A^A_ Attribute DragAndBropAwareType 
{ 



TYPE 

TT.^CLASS 

TT_SCOPE 

TT_ OPE RAT ION 

TT.PILE 

TT_ARG0_MODE 

TT_ARGO _VTYPE 

DESCRIPTION 



TT_KSG 

TT_REQUEST 

TT_SESSION 

Edit 

%Arg_l" Folder to open: 

TT_INOUT 

FTLE_ NAME 

Recjuest the File\ 

Manager to open a \ 

UBer-specif led folder 



} 



The TT_CLASS attribute spcrifips tf the message is a request 
or a notill cation. A request message reijuirea that the appli- 
cation that accepts tl>e message respond to the request. 
A notification me<5sage may be accepted by more tJian one 
application but no response is required. 

The TT_SCOPE attribute specifies tbe message's scope. The 
scope of a message is tyi:fically I he user's current C'DE ses- 
sion, lloweven a message can also be file-scoped. File scop- 
ing is used by apphcations t\mt are mterested in receiving 
message events for a specific file. For example, if a Tile- 
scoping-aware editor opens or saves a file, other- at>plicafions 
tlial are also fde-scoped to the same file wUI be notified of 
the operation. 

The Tr_OP£RATION attribute specifies the messages operation. 
The operation field may be application-specific, InU may 
also specify a generic desktop operation such as Display or 
Edit as defined by the message sei'vice s media exciiange 
message set. 

The rr_FlLE attribute specifies a file name for a message. In 
the example above, tlus field cont^iiiis a ke>^?ord that re- 
sults in the user being prompted for the name of a folder to 
open. The user's input wiU be placed in the message before 
i1 is sent. 

A message can have any numtjer of arguments. The argu- 
ments can lie used to give data to the scnicing application 
or to specify^ thai data shouJci be returned to tiie requestmg 
apphcation. The attributes rr_ARGi_MODE and TT_AF!Gt^VTYPE 
specify the input/<>ul(>i]t mode and type of a message for the 
ith message mgumem , 

Actions, Data Typing, and Drag and Drop. The data typing and 
action services can be coml)inetl to defme the tirag and drop 
semantics for a data type. Tlie foUov^ing data atirilntte defi- 
nition defines its default action (the action to be ijivoked 
when data of Ibis ty]}i? is opened) as Op en Action, This defini- 
tion uses the MOVE_TO_ACTIOM.COPY_TD_ACTJON, mil LfNK_TO_ 
ACTIO r\f attiibutes to define actions to be mvoked when data 
of tliis tyije is moved, copied, and linked respectively. 



ACTIONS 

M0VE_T0 ACTION 
# Move = Shift 



OpenAction 

Mo ve Ac t i on 
Mouse Button 1 



CO PY.TO. ACTION Copy Act ion 

# Copy ^ Control + Mouse Button 1 



LINK_TO_ACTION 
# Link = Control 



LinkAction 

+ Shxtt + Mouse Button 1 



I 



Action Service APIs, Tlie function used to uivoke an applica- 
tion , D t A c ti n J n V k e , h as several arginn ents. 1 1 o we ver, t he 
pai^ameters described here include the name of the action to 
invoke, an surny (3 f data arguments for the action, the number 
of ai'guments, and a callback fimction to be invoked when 
the action tenninates. 

The action name is used to find action records with tJie same 
name in the action database, and the signatme attribiUes of 
the matching action records are seai'ched to find a match 
with the .APFs data aigumenls. If a matcliing action is IVmrtd, 
tiie action is invoked and an action invocation id en till cation 
nmuber is retiuned to the apjilicat ion^ otherwise an error is 
returned to the application. Tlie data arguments can be fiU^s 
or memory buffens. If an action is defined to accept zero or 
one arguments tint more than one argiinient is pro\4ded, aji 
instimce of the action will be invoked for each iirgument. 

To be notified when an action terminates, an application can 
register an action termination callback when the action is 
invoked. This is particularly useful for applications that in- 
voke actions on behalf of embedded objects. For example, 
the mailer uses this featm'e to get not i lied when its attach- 
ments, wluch have been opened by at^ action invocarion, 
are closed. If an action has more than one action instance 
outstanduig, it can use the action mvocation itkuitification 
number to detemiine which action uistance tennmated. 

^Tien a data ai*giunent is a memory butTer, the app heat ion 
nuist pro\ide a [Jointer to the buffer, the size of the buffer, 
and an indication of whether the action is allowed to modify 
the buffer. Additionally, the apphcation can provide the data 
t>pe of the buffer and a file nanie template tCJ be used if a 
remi>orar>^ file for the bufTcr is needed. When necessaiy, such 
as when a buffei- is writable, the buffer is copied to a tempo- 
raiy file and the file name is used m tiie action invocation. 
Wlien the acrion terminates, tiie contents of the file are 
cojiied 1 I lie buffer, ajid the temporary file is removed. 

UNIX IS a fsgsste^ed tr3dEniaf< in the Uniied States and other countries, licenssd &3(clusivBlv 
through VDpen Companv Limited. 

VOpen is a registered trademaik and the X device is a trajjem^rk of X/Open Compafiy Limited 
in the UK and other CQuntrJes. 



2S .\j>ril m\G riewlt^tt-Packard JoumaJ 



)Copr. 1949-1998 Hewlett-Packard Co. 



Migrating HP VUE Desktop 
Customizations to CDE 



With CDE becoming the UNIX^' desktop standard, it is important to allow 
HP VUE users to preserve their customizations when moving over to the 
CDE desktop. A set of tools has been developed to make this transition as 
complete and effortless as possible. 

bv .Molly pJov 



The HP Visual User Environment (HP VT'E), combined with 
a set of applications, is a powerful graphical enviroiutient 
for interacting with the comjMiter, It provitles a coitsist^nl 
user interface and is based on OSF/Motif, which w;is created 
to enable different applications to behave tl^e same way. 
eiiminatiiig the need for users tx) learn multiple command 
sets to control applications. 

The t\eed for standards was recognized early by Hewlett- 
Packard with its support for iiTdiisti:^' staitdards such as the 
X Consortitmt mid the Open Software Foiutilation ( OSF). 
Aldiongh HP \^IE provided iLsei^ with an easy-to-use desk- 
top interface, there was no industry standard graphical user 
interface (GO) for desktop computer nunung the IINIX 
opemting system and the X Window System. What this 
meant was that e\en tlunigh Mol if applications t>etia\eft the 
same across multiple idatfonns diete w^as no cornrnonalily 
in the graphic^al user interface. whi<ii was referred to as a 
desktop. This was a serious limitation from the perspective 
of both the end user who had in learn to operate difrerent 
fiesktops it^ a lieterogeneous cf>mt>uling ejivironment and 
the application developer w ho had to develop and integrate 
appiications Into multiple desktops, TMs was also a cost 
factor in enterj irises with nuiltivendor cfmtimting en\4ron- 
menls because of the costs involved in ti"aining users and 
integrating new systems into existing heterogeneous net- 
w^orked envh'onments. 

Hewlett-Packard has a long-standing commitntent to open 
system standards. HP is one of four .sponsor companies that 
contribtitetl key Teclinoltjgies atid helped lo de^^'elt^ji CT.)E 
(Conutmu Deskloj) Environmeiit). CDPrs consistent look 
aiitl feel is based on ilP*s proven and ac'<*epted HP VT^E tech- 
nolog>' This rich graphical user interface has become a core 
component of CDE. 

Although HP \TJE and CDE have the same look and feel, the 
two technologies are somewhat different with the result 
being that HP VTJE customiscations ciuuiot be fiirectiy incor- 
porated LtUo tiie CT)E fleskio[) iutd be expected to work. 
IiP*s commitmem to su])ptHiii^g customer investment's 
dictated that a seantless tratisiiion from HP VITE to CDE 
was necessary. Even though a comt>leie transition is not 
possil>le in some cases, liie iment was to make the transition 
as complete and effortless as possible. 



Developing the MigraMim Ibols 

The decision to tlevelop a set of tools to allow HP VTrE-to- 
CDE migration was made in the second half of i9&4. This 
decision included ati agreement between Hew leti -Packard 
and TriTeal Con^oj^atlon to rievelop tliese tools jointly. 
TriTeal ai^d HP have a long history- with the HP \TT1 product 
because thrtnigJi a licensing agreement witli HP, TriTeal has 
mai'ketecl and s< ild HP-VT'E on MX Solaris, SUN, DEC 
OSF/1 and AT&T GIS operating systems, 

A customer surv-ey was conducted by HP in -bme 1994 to 
Jielp determine the user categories most concerned witli 
migration. 213 customers were randomly surveyed. We had 
a 34% (73 responses) response rate. Fig. 1 shows tile percent- 
age of respondents faUui^ uUo the various user categories. 
Respondents were allowed to select multiple categories. For 
example, almost dl of tiie resporuients wn-re ent! users, and 
65% of them were system administrators. 




OthBf 



User Type 
Fig. 1. Tfie categories of uBers interestEHi in migration Tools. 
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IVIigratlanTool 
Fig, 2, The areas nf intprest for the lype of mi^rattun l.uols. 

The sLir\^ey listed areas of HP \^JF] f iistoriiizations aiid 
asked customers to choose the aieas for which CDE must 
provide a iiiigraiion mechanism. Fig. 2 shows tliis list and 
the percentage of respondents choosing %'arious areas for 
migration. 

11 was decided etu^ly that the migral ion tools would he a set 
of shell scripts, modularized so that customers could run 
Ihem to suit their si>ecific neecLs. It was also recognized rhar 
although converters woulrl be wTitten to fleal wilh ttie com- 
mon kinds of customizadDiis, it would be impossible lo cater 
to all types and fomis of ctistomizalion. The tools would be 
written to be noninvasive aufl not change any of the HP VUE 
customi/.ations. 

The Dmerence Between HP VUE and CDE 

A brief look at the m^jor differences between HP VUE and 
CDE will help explain wliat the %-arious convertei-s written 
for migration have to accompUsli. Converters were written 



• Actions and file types 

• Icon image files 

• Toolboxes 

• PYont-paneJ and session custoniizations 

Actions and File Types. Actions make It easier to run apphca- 
Eions by represt^iling the applications as icons that can be 
manipulaled, VVlicn an at lion iy created, tlie application is 
intf^gryled into the users graplucal environment, teaching 
the desklo]) iiow to run the application. 

A file type [referred to as a data t>pe ui CDE) provides the 
ability for different ty|)es of files to have different appeal- 
ance im6 be]ia\1or. The file-t>T^5e aceomplisbes tins by; 

• iJe filling a unique icon for tlie each tile in the file manager 
windows 

• Providing a custom actions menu for tasks Lliat users do 
with data files 

• Providing context sensitivity for actions (for example, 
fiiffeient \ ersions of tlie i}ruit action can be w^ritten for 
different file lyi>es, creating a file-type-sensitive printer 
control lor the front panel ). 

Both IIP VUE and CDE use actions mid file (data) typing in 
the same way. Both maintain a databiise of actions and file 
type. 

File t^pes. used in conjunction with actions, cai^ be thought 
of as components that create a gtanimar for a user's system. 
If files are thought of as nouns, then file types are the adjec- 
tives and iictions are the verbs. Like grammar, the pieces are 
related to one another. Tliere ai'e mles that govern how^ they 
are put I ogetlier and how- they affect one another. It's these 
niles tfml have chajiged l)etween HP VUE ajid CDE, Tliis can 
be better iliustraled with action ajid file tyi>e definitions in 
the two environ n'k eats (see Fig. 3). 

Wliile action definitions have undergone only minor s^^inac- 
tical changes betw^een IIP VL^E and CDE, the file typ^ defini- 
tions have undergone some ma^jor changes between tlie two 



HP VUE 



CDE 



ACTION ImageViewClient 



ASG- TYPES 

TYPE 
WINDOW 'TYPE 

EXEC -HO ST 
EXEC- STRING 

L-ICON 
S-ICOS 

DE SCRIP TICK 



END 



C0MI4AND 
NO-STDIO 

hpcvuea 
usr/bin/Xll/tmageviewS, 

image vw.l 

imagevw , e 

This action invokes fcbe\ 

image Viewer, on. tlje\ 

client side if possible 



ACTION InageViewClienfc 

{ 
ARG-TYPE * 
TYPE COMMAND 

WINDOW- TYPE KO-STDIO 
EXEC_HOST hpcvuaa 
EXEC. STRING /usr/bin/Xll/im&geviewX 

^tFile)Arg_l^ 
ICON imagevw 

DESCRIPTION This action invokes ttie\ 

Image Viewer, on tbE client \ 

&16.& if possible 



F1I.ETYPS BM 
L-ICON 
S-ICON 
ACTIONS 
DESCRIPTION 

FILE- PATTERN 
END 



bitmap «1 

bitmap. 3 

I mageVi ewe 1 i ent 

A BM file contains data\ 

in the Xll bitmap format. 

•.bm 



DATA ATTE I BUTE S BM 
{ 

ICON bitmap 

ACTIONS ImageViewClient 

DESCRTPTION A BM file contains data in\ 
tlie xll bitmap format. 
} 

DATA_CRITERIA BMl 
( 

nATA_iVTTRIBirTES_NAME BH 

NAME_PATTSRN *.bm 
} 



Fig. 3> Action aiid file i>i3e defl- 
niti<His In HP VUE and CDE. 
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emlroninents. in addition, the 0Je naming convention and 
the kx-ations of files that contain actions and file types have 
changed berw^een HP XUE and CDE. 

Unlike the file ^^pe definition in HP \1. E, the CDE delinition 
consists of the following two separate d^&base record defi- 
nitions: 

• DATA_ATTRi8UTl. This definition describes tlie data type s 
nanie and the appearance and beiia\1or of files of iliis ijije. 

• DATA_CfilTERIA. This definition describes the limping criteria* 
Each criteria definition specifies the OAtA^ATTHtBUTE defini- 
tion to which the criteria apply- 
There most be at least one DATA_CRITFRIA definition for each 
DATA_ArmiBUT€ definition, A DATA.ATTRlBUTE definition cajt 
ha\'e miilti|3le DATA_CRtTER!A definitions associated with it. 
DATA^CRITERiA and 0ATA_ATTR1BUT£ records are described in 
the article on page 24. 

To allow apphcatiom integrated into HP YVE to be inte- 
grated into CDE, a converter had to be written to do the 
necessary syntactical conversions, Tliese Include the syntac- 
tical differences LUustiated in Fig. :j. as \^ ell j^is otJier^ not 
shown in Fig. 'S. Tlie tool also writes Uiese changes to files 
with the appropriate CDE suffix. 

Icon Image Files 

Icons are an imponant part of the visual appearance of both 
HP VlJE and CDE. Icons are associated 'tvith actions, data 
types, front -panel t*ontrols, and nuniniiKetl apf>li cation win- 
dows. For HP VI 'E components, icon image file iiiones use 
the convention: basename.siie. format, where basename is The 
name used lo reference the image, size indicates the size of 
the file (I for larj^e, m for rnediimi, or s for small), aiirl format 
indicales the t.vi>e of image Tile ( pm for X fnxniatjs or bm foi- X 
bitmaps). The dirferenr desktop conifjonents j^iich as ihe file 
manager anci ttre workspace manager choose tlie ict^n to be 
displayed based on the size fiekl in the icon nante. 

hi CDE, the same format applies. However, there are four 
different sizes: large (I ). medium fm), small f s), and tiny ft), 
and I he sizes me used ciilTertMUly. For example, by defiuiU 
the file manager in HP VT^E uses large (J) i(*ons whereas in 
CDE the file manager expects medimu icons (,mj. 'If> migrate 
these customized icons to the C'DE desktop, a tool was 
wTitten !o do the necessary' icon name ma|>pin}^ lo allow the 
customized icons to be tlisplayed by the dillVrejil CDE desk- 
top components. 

Toolboxes 

In HP VI 'E, toolboxes are contmners for applications and 
utilities. Each application or utility is represented by an icon 
called an action icon. The toolboxes in HP WB include: 

• Persona! toolbox. Tliis toolbox is t)ne that is j)ersonalIy 
conllgurpcl with actions cji'ateil by the us(t or copied from 
otJier toolboxes. 

• General toolbox, Tliis toolbox contmus applications and 
utilities built into HP WE or provided by the ?iystem 
administrator. 

• Ni'twork ioi>lbox. This toolbox allows the user to have 
ac-cess to actions on other systems. 

CDE replaces IooIIkjxcs with the af^pihation numager The 
aijpiication tuiuiager itUegnitcs loiid ajui remote* ajifiUcations 
into the desktop an(i [jresents litem to the user in a single 



container. A goal of the migration tools was to incorporate 
The personal and general toolboxes into the CDE desktop so 
thai die users could continue lo use tiieir favorite application 
or utility from the CDE desktop. A decision was ntade not to 
migrate the network toolbox because the HP M'E and CDE 
^proaches io the application sener are radically different. 
It is easier to configure a CDE application ser\ er ihan an HP 
\T'E aj>plieation sender 

Workspace Manager Customizations 

The workspace manager controls iiow \\-uidows look, behave, 
and respond to input from the mouse and keyboard In HP 
\XrE the workspace manager gets information about the front 
panel, wintkw menus, workspace menus, button bhidings^ 
aiKl key bindings from a resource file called sys.vuewmrc. ht 
CDE this information is divided into two flies, which reside 
in different locadons; dtwm.fp (front-panel definitions) and 
dtwmrc f men us, button and key bindings). 

Front-Panel Customizatioits, The front panel is a special desk- 
top \siadovv that cuniaiiLsa set of controls for doing conuiton 
tasks. The front lymwl has undergone a visual tis well as a 
defuiition change between HP \X E and CDE. In the citse of 
HP WE, there are three main elements to the front panel: 
the main panel, which includes botli tlie toji and l>oitnnt row. 
and subi>aneLs (Fig. 4a). hi CDE there Ls nt> Ijononi row. 
Instead, some of die controls that residetl in die HP VIE 
bottom row, such as the busy signal, exit, and lock buttons 
have moved to the workspace switch in CDE, while the 
other controls tire available tbnjogh the personal applica- 
tions slideup (see Fig. 4b). The toolbox ui HP VT'E has been 
replaced by tiie application manager 

Besides the visual differencx\s, tlie front -p^inel flefmitions for 
panel, box, ai\d control have also cliauged. To state it simply, 
in HP \^JE, a container (panel ) has knowledge of its contents 
(box), but a box has no kttowledge of its pjmnit f jnuiel). In 
CDPI die reverse is true (e.g., a box knows about its tJJrueiU 
(panel), ajid a control knows atxnit its jjarent (box) but not 
vice v^ersa Fig, 5 shows these differences. 

Since there were boUi syntactical and logic difference!^ be- 
tween the HP VlJE and CDE front panels, this was otie of 
the most difficult converters to wril<v White iiresenpirig u.ser 
ctisbHtii/aii^ins. the converter also had lo iepla<*e HI' \T'E 
controls with their e(|uivalcnt CDfil countcriJ^wl-*' (^'-Si '^ 
placing tJie toolbox with tlie applicatioit manager). In the 
case of a one-tf>c»ne mapping between an HI* VI "E control 
and a CDK control such as the mail icon, die converter has 
to migrate atiy custoniLzalions made to these controls in HP 
VlIE or replace them with the i*quivaient CDE defaults. 

Session Custom izat ions. A session refers to the state of the 
desktfjp between the time the user logs in and the time the 
user logs out. A session b ch;iracterizc«l by: 

• The atipHcalirius that iire mtvniug 

• The icons on the desktop 

• The look (colors^ fonts, size, location, etc.) of application 
windows 

• Other settings controlled by the X server such as motise 
behavior, atidio, volume, aiKl keyboard click. 

Sessions are divided into two categories: current sessions 
ajid borne seissiotis. A i-urrent sessirjn is one that is sttjred at 
logout so that when a user logs in again the session state at 
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Fig, 4, (ci) HP \t:iE deikult front panel, (b) COE default fim it paneL 
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Control 



logout is reestablished. A home session, whlcli is ex|ilicitly 
stored by the user at some other time during a session, 
allows the user to return to some known session. 

Session information is stored in the tiles listed in Table J, 

Table I 
Session Files 

File Contents 

vue session The names of active clients and their 

window geo merries, workspaces, states 
(nonnalized or niinimized), and startup 
strings. 

Tlie resources for the active clients 
(incluciing the workspace manager) m 
tiie session. 

Server and session manager settmgs such 
as scr een -saver 1 hue out. audio, and key- 
board repeal. 

Since the goal of ttie migration tools was to allow a seamless 
transition from HP \TTE to CT)E, we delemiined that it was 
necessaiy to bruig over U\e users' sessions, so Lhiil tiieir CDE 
sessions resembled HP VUE sessions as much as possible. 
A converter was written to convert the appropriate session 
files to theii' CDE equivalents. This meant creatiJig equivaleru 
dtsession, dtresources, and dtsettfngs files witli the names of HP 



vue. resources 



vue. settings 



VUE clients being replaced with their CDE counterparts if 
they existed. For example, substituting Vuewm mth Dtwm and 
Vueffle with Dtfile. 

A Graphical User Interface for Migration Tools 

While the indivitiiial converters were being developed, a 
grapliical user mterface for the converters was being 
designed. Migiation tool tisei\s cat^ be (Classified Into two 
groups: system administrators and end users. The interfaces 
for the migration tool had to L>e tailored to the iieeds of 
these two types of users even though the converters being 
used were essentially the same. This involved several itera- 
tions on paper of the vaiiotis dialogs fiiat would take tlie user 
thjough the migiiition process. Since all of the converters 
were written usmg sheU scripts to allow easier modification 
by the cuslfinier if needed^ a tlecistoji was made to use diksh 
for develoijiiig the GLTL Dtksh is a utility that provides access 
to a powerful user interface from Kom sheO scripts. Dtksh is 
part of the CDE APL 

The different converters were gathered together into a 
migration application called VUEtoCDE. To nm the migration 
tools, the VUEtoCDE migration prociuct has to be mstailed on 
the system after CDE has been ijistaJled. The first time the 
user (s>'stem administrator or end user) logs into the system 
the migration dialog box {Fig. 6) appeals if the users liome 
directory contains a .vue directory. The assumption here is 
thai the user has used HP \T.!E and might choose to move 



32 April 1996 Hewlett-Packard Jtmmctl 



)Copr. 1949-1998 Hewlett-Packard Co. 



HPtfUE 



CDE 



PhMEL Fx-QiitFaii^l 



/* Parent refereac«s 



BOX 
BOH 



BOX Top 
C 

TYPE 

COHTBOZ. 

COMTROL 

CONTROL 



) 

CONTROL Cloclc 
( 
TYPE 



Top /• cMld */ 

Bottom ^* child •/ 



pr±iEarY 

Cioc^c /• child */ 

Pate f* child */ 

l,Qad y child •/ 



clock 



>JW!XL Front Fane 1 


/* Parent has as references to 


f 


children */ 


DI S FLAy_BAKBi.SS 


True 


DISPLAY HBSU 


True 


Ol SPLAY ^MliHICtEE 


True 


GO«TRQIi_HEai VI OB 


»lagle_ciick 



DISPLAY_C01ITaOl/_UiBEi^ False 

ilBLP TOPIC PPOnlteinPront panel 

HEi»p_VDUn«iE rpaii0i 
) 



BOX Top 

{ 

COHTAXMER_SAME Front Panel 

POSITION. HI J?TS first 

HELP_T0FIC FPOnltemBox 

aELF_VOLtJMB FPanel 
} 



/•child refer ences parent 



SUB PANEL 


clocksubpanel 




CONTROL Clock 




KELP_TOPIC 


FPClocJt 




{ 
TYPE 

C ONTAINER_NAME 
CONTAINER TYPE 


c 1 ock 

Top / 

BOK 


iQ)L ClochSubpanel 




POSITION, HINTS 
ICON 


1 
Fpclock 


TYPE 

TITLE 
aSLP_STIlING 


auhpanel 

"Thi© auhpanel contains 
time -related fujatioua" 


LABEL 
HELP„TOPIC 

HELF_VOLTJME 
} 


Clock 
FPOnJtemClock 

FPanel 


CONTROL 


JapaJiefleClock 









child references parent 



CONTROL JapajieaeClock 



TYPE 


button 


IHAQE 


clock 


FUSH_ACT10N 


f ^ ac t ion TinteiTsp ane b e 


LABEL 


"japsm" 



SUBPANEL Clockaubpaael 
C 

CONTAIHSR_HAKB Cl»OCK /* child references parent */ 

TITLE "Time Zones'' 

> 

CONTROL JapaneseClOck 
< 

TYPE icon 

CONTAINER MAKE ClackSiibpanel/ ' 

CON"TArNER_TYPE SUBPAl^L 

POS IT 10N_ HINTS 

ICON 

LABEL 

PUSH_ACTI0M 

HELP TOPIC 

HELP VOLUME 



child references parent 



1 

clock 

Japan 

Time Japanese 

FPOiil t emc lock 

FPanel 



> 



Fig, 5, Fnml \miB\ dermitions ill HP VUS and CDE. 

HP WE 3.0 ciist£)nuziilii»n.s to CDE. Severd options wre. pro- 
vided Ijy whk'h llie user roiikl migi*ate now or later or not at 
all The user caii invoke the tool from ttie application man- 
ager at any time. 

If the user chooses to migrate, the rool detemimes if the 
user is a system adntinistrator or mi end user and presents 
the appropriate dialog. Fig, 7 is the dialog presented to the 
end user when the Yes, Now button is selected. 

The thinking here was that more often than not, the user 
would clvcjose the one-step migration (default option), but 



WetcoiDe to the Comirion Desktop EnvUdnmerie J 

t>0 you wish ta migrate your VUE 3.0 cusfomizotions to COE? 



Yes. Now I Mot Nowi Ut«r 



Flgi 6. tiLirial inigraUon tilalug. 



we w^ante^i to provide choices for tliose who didn't waiit the 
default option. Also, by choosing the various coiwerter op- 
tions, tlie user eaii exercise a specific converter in the event 
that it did not work as expected in the one-step migration. 

The converters were designed to a\'oid modifying any of the 
HP \TTE directories, allowing the user to renm the converters 
as many times as needed. In f.he case of actions, file tJT'es, 
and icons the com erter expects an IIP Vi*E source directory 
iuid a CDE dei^tinatitJn threctoiy. Tliis allows the user to 
enter nonstandard source and destinaticjn local if>ns for 
action. Tile lyi>e. mul icon miage files. WluMi ii nonstan<iard 
destination is entered, tlie tool displays a message that this 
path ha.s to he added to the user's dtprofiie Hie with a specific 
inijui environment vai iabtc to nptlate the global seim'h j)ath. 
This oiffion was chosen over having the loot modify the 
users dtprofiie, which wtus considered to i>e too invasive. 
Initially, the user is presented with the default HP WE aiicl 
V\)E locations (see Fig. 8), but the user can i:y\)e in as many 
St) art H^ and destination ditecti>ries as «lesirect 
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Migrate selected customizationsi 



I Actions and Filetypes 

1 Icon Image Files 

r~ Personal Toolbox 

f Front Panel and Session Files 



Vl Migrate all customizations 
(All of the above) 



fc^ 



Cancel 



II 



Fi^, 7. Usi.^1 -level niigriilicjn. 

Because of the shift from toolboxes in HP VlJE to t.!ie appli- 
cation manager in CDE, the migration of a toolbox to any 
location other than ilie CDE api:>lication nmnager is not 
straightforward. It requires some in-deptJi understaiiding of 
Iiow to integrate applications into the CDE flesktop before 
tlie user can specify a nonstandtircl destination for an IIP 
VUE toolbox. Tluis, the migration tool disallows specifying a 
nonstandard destination and only pro\ddes the flexibihty of 
choosing the name of the application group for an IIP VUE 
toolbox (see Fig. 9). 

Each converter that is iim generates a log lile in a directory 
prepended widi the user's logui name (e.g., mollyj_VLie2Cde_LDg) 
in /imp, allowing for faster diagnosis of problems. 

Wlien the user has completed tlie pei'soual migi'ation. a final 
dialog is displayed that contains a sjiecial button for exiting 
the current CDE session. This button is necessary because 
of the design of the CDE session manager. Ordinarily, when 
Ihe user logs out, the contents of the cinxent session are 
written to the current sessioit connguratiou files, overwritiug 
the previous contents. 'H^rs, if t!ie user were to simply log 
out after migration, the migrated session Jiles would be 
overwritten. To prevent this problem, 1 be CT)E session man- 
ager provides a special termination option used only by the 
VUEtoCDE tool. Tliia option ends the current session without 
saving it so that the migrated session inforn-Eation is pre- 
served and availabie at next login. 



Smirce Path ^ VUE): " "^B&nstion Path tCOCjj 

y user s/uiol lyj/ . vue/ types I ; /users/niol ly j/ . dt/type^ 



Sourc* P«<li CHf^ VUE) : ApplfcaHofT Grmtp Nmnv (COE) : 



Fig. 9, Tofjjbox cuiivtTSiou, 

Migration of a User's Front-Pane J Customizatioiis 

C'onsider the simple case of an HP VLIE front panel that has 
been customized to add a media control w ilh a {x>rrespond- 
mg subpaIu^l in the top row^ imd an icon l>ox in tlie bottom 
box (see Fig, 10). Tlie user riuiniug the uiigration too!s would 
expect tiiese controls to be migrated over to the Ct)B front 
panel. The results arc* shown in Fig. 1 L The media subpanel 
has been migrated to the mam CDE front panel and t he icon 
box to the personal appheations subpanel because of the 
absence of a bottom row in tlte default CDE front jianel The 
personal appheations subpanel and the apph cation manager 
icon aie [jlaced after ttic trash icon. Tliese two ctintrols do 
not have analogs hi IIP \XIE, and a decision had to be made 
regaidmg the placement of tliese two controls on the con- 
verted front panel. Since an HP WE front panel could take 
any shape or form (multiple rows versus just a top and bot- 
tom rowO, a definitive loeatioji was needed for these two 
controls. A decision wa^s made (o place tbem as the last tw^o 
controls of the last row in tlte etjnveited front panel Tliis 
conversion can be achieved either by clicking tJie IVligrate 
i)utton on the dialog box shown in Fig. 7, which results in 
migrating all customizations, or by selecting from the same 
dialog box one of the following options and then chcking the 
Migrate button: 

• Actions and Filet/pes 

• Icon Image Files 

• Front Panel and Session Files 

Now that we have illustrated how tJie tools convert a front 
[>ar^el with some relatively sun pie customizations^ we would 
like to illustrate what the migration tool can do in cases 
where the customizatious are complex and utk onverst ionaU 

Fig, 12 shows an example of a Iiighly cnstomized IIP VUE 
front panel It's a box with five rows and several subpanels. 
During the development |)hase of our project tins panel w^as 
considered to be tlie ul tun ate test for the front-pmiel con- 
verter. Tliis front panel helped shatter several assumptions 
matle m the design and pushed the limits of tlie front-p^uiel 
converter Tlie desire here wds to presence the row posit Ions 
and subpauels while modifying the frt>nl panel so that it ton- 
formed to the CDE default front panel. Wliat we ended up 
with is a reasonably accurate conversion (Fig. 13). The IIP 
WE front i)iirtel hat! live rows, one of wliich was the bottom 
row. This rianslared i o four rows ui CDE since the default 
CDE front panel does not have a bottom row. The HP WE 
controls in the bottom row (e.g., lock, exit, and busy con- 
trols), for which there aie CDE equivalents, m'e not migrated 
unless they have been customized. Tliis also apphes to the 
lernunal window and text editor controls in tlie bottt>m row 



Fig. 8. Ac u OILS and llip K'pes conversion. 
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Icon Bax Control 
Fig, 10. User's eustomixed HP VLIE front paiieL 

for which there are CDE equivalents in the personal applica- 
tions slideup. Any other castoniized controls in the bottom 
row are also moved to the pei'sonal applications slideup. 

HP VITG controls that i\o nfit map to controb in CDE are 
removed. Keeping (iii^ in mine!, note \he one-lo-fme mapping 
of controls to rows belvv(;pn (he HI* \'VH pyiie^l in Fig. 12 and 
the CDK panel in Fig. i'i, What is iincxpected is I lie extra 
space seen at the end of rows in tlie converle(J WK front 
panel The reason for tins h ihat the atjplicat Ion numager 
and Llie personal api)lic'aliorLs slidiup, whidi have an aiialogs 



in IIP VUE, need a definitive location m the converted front 
panel. The decision to place tliem as the last two controls in 
the last row^ of the converted front panel has resulteci in this 
row bemg rather long, cn^ating tlie c^xlra spac^e. Other factors 
that have contrit>iited to this extra sjiace are the area aixumd 
the w{>rksi>acc switch, which did nut exist Ui HP VUE. the 
si>ace laken by the window fran^e, which was missing in the 
HP VLi E front panel, an<i the sis^e of the default workspace 
buttons in CDE, wiiicli aie wider tiian their HP VTIE counter- 
parts. 
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Fig. 12, A hijgiily cusi omiserl HP WE front prnxd. 

System- Level Migration 

In designing tJie sysleiTi-lcvd migration, the tliiiikiiig was that 
system administrators typically do not like one-step migra- 
tions but would much rather do a stcp-by-step migration to 
allow more control Exactly the same convertei^ available 
to the user ai-e availatile Iiere with the defaults being set to 
system level. Log file?^ lor the converters aie created in a 
directory called SystBm_VuetoCde_Log in /tmp, Tlie system-level 
migration options and the front -panel and session files con- 
version menu aic shown in Fig. 14. 

Reinote Execution firom the CDE De^iktap 

In addition to the options specified in the VUEtoCDE-System 
Migration Options dialog in Fig. 14a, a command-line converter 
is available to create a nunimum CDE fileset for remote 
execution- 
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VI Front Panel and Workspace Manager configuration 

file (sys.vuewmrc) 

yi Default session resource file (sys. resources) 
V Oefault session startup file (sys. sessions) 
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Fig. 14, (a) System-level ruigraQon options, (b) Frcmt-r^^^f] 
mui scission files cou version. 

Tlie fileset required on a remote machine for an IIP YUE 
action to execute remotely is dilTerenl from llial retiiiiretl lor 
CDE remote execution. While HP VlJE requires the sped ser- 
vice, CDE relies on dtspcd and ToolTalk'"' services. Sped, 
dtspcd, and ToolTalk are services that allow actions to invoke 
applications that rim on remote machines. A conveiter was 
written to build the minimum CDE fileset that could then be 
installed on the remote machine (if CDE is not already 
installed) to allow actions to continue worMng from tiie CDE 
desktop after migration. This converter does not pro\ide as 
complete a migration as some of the other converters 
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Fig, 13, A migrated CDE front 
panel, 
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because sj'slein fUes have to be modified nmnually as weli 
Ne\'eithele^ it was felt tbai any form of help pro\ide<i 
during this transition from HP WE to CDE would be worth- 
while. 

Usability Hasting 

The migration tools underwent usability testing at HP's 
Corv^aDis and Fort Collins laboratories. Se\^eral sjsteni 
administrators and end users were asked to run the mi^a- 
tion tools. These sessions were remotely observed by the 
engineer conducting tlie tests. Tliese sessions were also 
videotaped and reports were put together by the usabili^ 
engineer and sent to the learning produtts and de%'^elopment 
engineers. This input was used to further modif>^ the tools* 
online help, and docmnentation. l^lost often the confusion 
was over the choice of names for buttons or not ha\1ng 
enough feedback w^hen a task was corapleied. 

Conclusion 

Although the migration tools described here do not provide 
a con^plete migration from HP VUE to CDE. the converters 
do bring over a large portion of a users customizatiotis 



through an easj -to-use graphical user interfece. Since HP is 
committed to its customers^ w^e will continue to support HP 
WE as long as our customers want it, but we hope that 
these tools wHl be an incenii\'e for HP \T.X users to embrace 
CDE sooner radier than later and make CDE the true desk- 
top standard. 
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A Media-Rich Online Help System 

Based on an existing fast and easy-to-use online help system: the CDE 
help system extends this baseline to provide features that will work 
across all UNIX^^ platforms. 

by Lori A, Cook, Steven P, Hiebert, and Michael R* Wilson 



With the growing demand by users for a unified desktop 
strategy across all UNIX operating system platforms comes 
the requirement for a stan^daid help system. Users expect 
some btise level of online help to be pro\ided from witliin 
ttie desktop they are using. They expect online infonnation 
Lo be easy to use and graphical, witli growing expectations 
of direct audio and video support and intjeractive capabilities* 

The Common Desktop Environment (CDE) help system pro- 
vides media-rich, onlit>e information that is both fast and 
easj' to use. It: has its basis in the standard online help system 
from HP tJiat is used extensively by HP VX^E :J.O and HP 
MPower^ components and by maiiy other HP (!)SF/Motif- 
based products. 

Background 

The CDE LO help sysiem originated with HP \T_'E. i\n early 
venjion, HP VTJEhelp 2.0, satisfied few of the requirements 
of a modern help system. VirEbelp 2.0 did nut allow rich 
text and graphics, was hai'd to integrate into an apphcation, 
lacked authoring tools, and suffered from poor peri'onnance. 
The HP VI JE 3.0 help system delivered a complete solution 
for creating, integratiiig, and sliipping lich online infonna- 
tion with an OSF/lVIotif-based apphcation, wtnle keeping its 
presence (use of system resoiurces) to a minimmn. HP \TJE 
3.0 wallced a veiy fine line between providing tihc rich set of 
features that customers required while maintaining perfor- 
mance. In 95% of the cases where features and perfonnance 
came into conflict, performance won. The HP VLJE 3.0 help 
system was submitted to the CDE 1.0 j>artnei's for considei- 
ation. It was tlie only existing, miencumberedj rich text help 
system put for^vaid for consideration. After an evaluation 
period, the IIP VLTE 3.0 help system was accepted almost as 
is. It contamed all the fimctionality required, and witli a little 
work, it coir Id use a stiindard distribution fomiat. 

The Help Developer's Kit 

Tlie CDE LO developers kit includes a complete system for 
developing onlUie help for any OSF/IVlotif-based apphcation. 
It allows authors to write online help that includes rich 
graphics and text formatting, hyperlinks, and communication 
with the apphcation. It pro\1des a program rner's toolkit that 
allow^s developers to integrate this rich online help infonna- 
tion v^ath their client applications. The help dialog widget 
selves as the main display window for tlie CDE LO help 
system. A second, lighter-weight help wklget, called quick 
imlp dialog, is also available from the toolkit. Following is 
the list of components supported within the toolkit: 



For authors: 

• The CDE 1.0 HelpTag markup language. This is a set of tags 
used in text files to mark the organization and content of 
online help. HelpTag is based on SGML (Standard General- 
ized Mat klip Language). 

• The CDE LO HelpTag software. Tliis is a set of softw^aie 
tools for converting the authored HelpTag iiles into tLeir run- 
time equivalents used to display the online help uifonnation. 
CDE ] .0 HelpTag is a superset of the HelpTag used witii HP 
\T:E ;10. HP \^ JE 3.0 HelpTag source files compile under 
CDE 1.0 with no modification. One exception to this is if 
authors use the old HP \TrE 3.0 help distribution format. 

• The dthelpview application, Tliis program is for displaying 
online help so it can be read and interacted with in the same 
manner as end users wiH use it* 

For prog rammers: 

• The DtHBlp progranmiing library'. This is an application 
programming interface (API) for integrating help windo^vs 
(custom OSF/Motif i^idgets) into an apphcation. 

• A demonstration program. This is a simple example that 
shows how to integrate the CDE LO help system into an 
OSF/Motif apphcation. 

Changed or new features for CDE 1.0: 

• Pubhc distribution fonnaf leased on SGML conforms to 
standards. 

■ A new keyword searching capability allows users to search 
across all volumes on the system, 

• A new history dialog aUows the user to select previously 
\1ewed volumes. 

• A different table of contents meclianlsm allows fdil browshig 
of the volume vtltiiout using hyt>ert ext Unks. 

• A richer message formatting capability is provided. (Wliile 
HelpTag does not allow tables, other documents that do 
allow tables can be translated into the pubhc distribution 
fomiat and displayed. Also, the table of contents now 
allows graphics in the titles.) 

• Public text extraction functions are removed^ but available 
for old IIP VUE 3.0 users by redefining. 

General Packaging .Architecture 

/\n online help system needs to feel like it is pait of the host 
application to the end user, not an appendage liangutg off to 
tiie side. For developers to leverage a tl\ird-part>^ hel]D system, 
it must be delivered in such a way tis to pio\ide easy and 
seamless integration nUo their applications. Furthermore, 
the efifort and overhead of kitegrating and redistributing the 
help system along wiUi ttieir apphcations must be minimal, 
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while al the same time meedng application and endmser 
re*itiirenienis for a help system. I'sers should feel as if they 
have nev er left the application while getting help. 

During the initial pfmot^ing of the HP WE :iO help s>^em, 
two key issues kept occurring: performance and packaging. 
The help system needed to be light and fast and easy to inte- 
grate into any OSF/Motif-based a|jphcaiion and redistribute 
with that applicatioa HP WE 2.0 help suffered gready on 
boUi these points. \lJEhelp 2.0 was serv-er-based. large, 
slow, and dependent on the HP WK desktop. jVny applica- 
tion using this help service tiad to run within the HP Vl.^ 
desktop environment. 

These two issues were addressed in HP VUE 3.0 help and 
we found no reason to change the paradigm in the CDE 

development. To fix the performance problems (slow startup 
rimes), funetionalit>^ is linked into the client \ia a librarj' 
rather than starting up a separate help sener i>roceas (as 
was the case for IIP \T.^ 2.0). Since most C)SF/Mc:>tjf ai:jplica- 
tjons tend to incorporate the same \^idgets as those used by 
the help dialogs, the increase in data and text for attaching a 
help dialog to an application is niininial. 

Fig. 1 represents two different approaches to integrating on- 
line help into an application. Our initial prototypes quickly 
exposed the value of a client-side embedded solution espe- 
cially with respect to performance (e.g., fast retideritig time) 
and memory use* 

The following advantages are gained by usijig a library- 
based hel]> system instead of a serv^er-bascd architecture. 

Integration advantages: 

• OSF/Motil-Uis('<] API [simple to use for Motif knowledge- 
able developers; 

• Application control of the help system dialog management 
(creation, destrmtion, cacliing, and reuse) 

• Stnooth Iraitsiiion intt) help system via consistent resource 
settings between the apijliration aivtl the helt> system (same 
fonts and color scheme and qiiick response times) 

• Ready supf>oi1 for a tightly coupled application-to-help- 
system environment (application defined and processed 
heit> controls such as hyj^erlext links J 

• Api>li<'ation~spe(irie ciLstomizing of the help system 
{dialogs, controls, resources, and localization). 



Embedded 
Help SysiBi^ 



CI f ant 
Applicatinn 



(Bl 




Emlieitded 
Help Systent API 




Help Server 
Application 



Fig, 1, Two differt'nt nppnmvhm to intc»gratini; onliivc iiolp into aji 
appJication. (a) Client si rif» trnibc?dded iinplnnmtuation. This is; the 
Rchfiiie meA\ in (vDE LtJ. (b) iSprver-siflf* iiiiplpriu^utatioii uf t^e 
help jiyslein. This was thp irnplf^nientatiori used in HP VfJE 2.0; 



CDE dependencies: 

• DtHelp is delivered in sliared-Ubran^ form only. 

• AppUcanon must Unk with the CDE libraries DtSvc and tL 

• CDE is noi required as long as the hbraries it depends on 
are av'ailabie. 

Integration Concepts ^ Practices, and Mechanisms 

The int ricacies of how to autlior online infomiaiion, or the 
diflereni ways a developer can integrate help into an appUca- 
don. are described in the CDE 1.0 help ^rsteni dev^etoper s 
guide. We will describe in this section ihe general integm- 
tion concepts and practices for which this help sy^stem was 
intended. 

The nin-tinie help facility is made up of a collection of help 
dialogs (complex, composite widgets), and compiled help 
V'ohtnies (described below). The help widgets are linked 
directly into the client application via the help librarj' 
lihDtHelp.sl (shared hbrary ) and ii\staiitiate<1 by the client to 
display help information. Tlw help ditdtjgs sene only as the 
vehicle for displaying rich online help information, wliile 
standard OSF/^IotLf, Xiib, and Xt services ser\'e as the glue 
to integrate them into the ai)plication. For tliis reason, it is 
necessaiy to stray from disctissing the si)ecifics of the help 
sj'stem and its coiiij>onetUs, and describe some of the ()S?7 
Motif mn] toolkit met luuiLsms that must be used to integrate 
help into an application. 

There are two levels of integration with resj^ect to tliis help 
system: integrating help into an application and integrating a 
help-smtul application into (T)E. 

Integrating Help into an OSF/Motif Application 

Developers have many degrees ol' freedom with respect to 
how much or how little help tliey include in their applica- 
tions. If an application iuid its help itdbrmation have very 
loose ties, there may be only a handful of topics that the 
application is able to display directly. In contrast, the appli- 
cation could provide specific help for nearly every ol^jcct 
and task in the application. This requires more work, but it 
provides potentially mucli greater benefns to the end user if 
done well. 

Melp menus ;tnd buttons in an application st*rv'e as Uie niost 
basic of lieip entry points for an api]licati(jn, RefetTnce 2 
provides more itifonnation abonl integrating help menus 
and buttons into an apphcaiion. 

Cdntextual Help. Contextual helfJ provides help information 
riljDiil the in in on which the selection cursi>r^- is positioned. 
Contextual help infonnation prtmdes users wilJi infonnation 
about a st>ecific item as it is currently used, Tlie Lnfonnation 
pn)\ided is specific^ lo the meaning of the item in its rnrreni 
state, 

Thf^ OSPYMotif user interface toolkit r>rnvif!es direct support 
for contexlual help t^utry [joints via its lu'lf) callback mecha- 
nism. When a valid help caJlliack is arlded lo a widget and 
the user presses the lielp key (Fl ) wliile that widget has the 
currenl kcyinjard focus (selectiun cuj'sor), the widgets help 
callback is automatjcally executed. From witliin tite help 

' A seiecuon cuisar is visual cue Itiat allows lisai s to indirai^ vuiili the kflybDard the item with 
which They wisti m Interact IE i$ typically mprsssriied by highl^yhtmg tl^a choice with m 
outline boit. 
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callback tlie application has the opportunity to display some 
iielp toiiJic tUi^cctly based on the selected v^idget, or the appli- 
cation could dynamically construct some help hifomiation 
based on the current context of the selected item. 

Any level of granularity can be applied wheii addmg help 
callbacks to an application's user interface components. 
They caii be added to dl the v^idgets and gadgets within tlie 
apph cation dialogs, to the top-level windows for each of the 
dialogs, or to any combination in between. 

If the user selects Ft help witJi the selection cursor over a 
widget or gadget diat has no help callback attached to it, the 
OSF/Motif help callback mechanism provides a clever fall- 
back nieclianism for providing more general help. The help 
callback mechanism will jump to the nearest widget ancestor 
that has a help callback assigned, and mvoke that callback, 
Tlie theory is that if you don't have a specific help on that 
widget or gadget, then it*s better to provide more general help 
than none at alL 

Application developers are responsible for adding their own 
help callbacks to their user interface components within 
tlieir application. OSF/Motif sets the help callbacks to NUtL 
by default. 

Item Help. Item help allows users to get help on a particular 
control J such as a button, menu, or window, by selecting it 
with the pointer. Item help infornmt ion should describe \l\e 
purpose of the item for which help is requested and tell users 
how to iJilerac^t with that item. This infonnation is typically 
refer ence-o rientc d . 

Item help is usually accessed via an apphcation's help under 
the On item menu selection. Once selected, the selection cur- 
sor is replaced with a question mark cursor and users can 
choose the item on which ttiey want help by making the 
selection over that item. 

The CDE help system API utihty function DtHelpRetumSeiected- 
WJdQetJdd assists developers in pro\iding item help \\ithin 
their applications. Tliis function provides an interface for 
selection of a component within an applicalion. 

DtHelpRBtumSelectedWrdgetfdO will retimi the widget ID for any 
widget in the user mterface that the user has selected via 
the pomter. The application theri has the opportunity to dis- 
play some help infonnation directly on the selected widget 
or gadget. 

At any point while the question mark cursor is displayed, tlie 
user can select the escape key (ESC) to abort the hmction call 
If the user selects any item outside die cmTent applications 
vvindow, the proper error value will be returned. 

Once DtHelpREturnSefectedWidgetldO has retmned the selected 
widget, the apphcation can invoke the help callback on the 
relumed widget or gadget to process the selected item. 

From within the help callback, the apphcation has the op- 
portunity to display some help topics based mx die selected 
widget, or it could dynamically constmct some help infor- 
mation based on the cun ent item selected. 

Integrating a Help-Smart Application into the Desktop 

There are no restiictions regtixtOng where nin-time help files 
are installed. However, a suggested practice is to set up the 
help file Lnstallation package with the abihtjr' to redirect the 



default help file install location (e.g., put them on a remote 
help sen'er systjcnij* By default, the run~tm\e lielp files should 
be installed with the rest of an apphcation's files. Installing 
the run-time help files in tlie same location as the applica- 
tion s flies gives system administrators more flexibility in 
managing system resources. 

An important step in installing help fdes is registration. The 
registration process enables two iniportiuU fc^atures of the 
CDE hO help system: cross volume li.vTcrlinks imd product 
family browsing. 

Registering Help Volumes. After the run-time files have been 
installed, the vohmie is registered by running the CDE 1 .0 
utility, dtappSn teg rate. This utility registers tlie application's 
help volume by creatmg a symbolic link from where the help 
volumes are installed to the registry ciirectory /Btc/dt/appcanfig/ 
heEp/<$LANG>. By using tlus utihty to register the help vof 
urneSj the application can ask for a help volume liy its name 
only and the DtHelp hbrary will search the standai'd locations 
for the vohmie's registry. Then, no matter where tjie applica- 
tion's help vohmie ends up, the DtHelp Ubraiy^ finds the sym- 
bolic Unk in a stiuidard location and traces the link back to 
the real location. The article on page 15 describes registra- 
tion and the utility dtappintegrate. 

If access to an apphcation 's help volume is restricted lo the 
apphcation, then the location of the help volume can be liard- 
coded into the application. The disadvantage of this method 
occiu^ when a system administrator moves tiie application's 
lielp voluntes to another location. Fthe application looks in 
only one place for the help infonnation^ moving tiie help 
volume causes a serious problem. 

Registering a Product Family. Wlien registering a product fam- 
ily, vi'liich is a group of help volumes belonging to a particu- 
lar product, a help family fde (prDducLhf) should be created 
anti installed with the rest of the product's help files. Tlie 
dtappintegrate utihtj^ creates a s^mbohc hnk for \he product file 
to a standard location where the browser generator utihty, 
dtheipgen. can find and process it. The dthelpgen otihty creates 
a special help volume that lists the product families and the 
volumes within each family installed on the system. 

Access to Help Volumes 

Tlie CDE 1,0 help system has a simple, yet extensible mech- 
aiusm for' transparent iujcess of help volumes installed on the 
desktop. It supports both local and remote access to help 
volumes and works wilh any nimiber of workstations. The 
only dependencies required are proper help registration 
(discussed above), NFS ser\ices (i,e., remote systems 
moimted to the local server), and proper configuration of 
t!ie help environment variables discussed below. 

When an application creates an instance of a help widget the 
DiNhelpVolume resource can be set using one of two formats: a 
complete path to the volume.sdl file, or if the volume is regis- 
tered, the base name of the volume. Ulien using the base 
name, die help system searches several directories for the 
volume. The search ends when the first matching volume is 
found. The value of the user's StANG enviromnent varial>le is 
also used to locate help in the proper language (if it's avail- 
able). 

DTHELPUSEflSEARCHPATH. This environment variable contains 
die user-defined seai ch patii for locating help volumes. The 
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default value used when this environment variable is not set 

is: 

• d^eip/%T/%l/%H: \ 

• dt/hel0/%T/%l/%H.sdli 

• dt/htip/%T/%U%H.hv: 

where: 

• %L is the value of the $LAHB eoviionniem variable (C is tbe 

default) 

• %H is the DtNhelpVQlume (help volume) resource specified 

• %T is the type of file (volume or faniilyj being searched for, 

Wienever this resource is set to a relative palii, the resource 
v^alue will be prefixed wilii the user's defeult home directoi^". 



Examples: 

Help volume: 
Product family: 



/jser/vhelp/vo3umes/C/reboothv 
/u ser/ vh e I p/f am ii v/Sh a r edX. hi , 



The iiv and .hf extensions are provided for backwards com- 
patibiUt^^ with the HP VUE 3.0 help and family volumes. 

DTHELPUSERSEARCHPATH supplements any system search path 
defined. Therefore, the luser uses this environment variabie 
to access help volumes that should not be available to every- 
one. 

DTHELPSEABCHPATH. This environment variable specifies the 
s>^stem search jiath for locating help volumes. The defatilt 
values used when this environment variable is not set 
include: 

- /etc/dt/appconfig/he!p/%T/%Ly%H: \ 

1 /etc/dt/appconfig/help/%T/%t;*)t.H,sdi: \ 

► /etc/dt/appconfig/help/%T/%U%H.hv: \ 

^^^cre: %L, %H, and %J are the same as above. 

When setting either of these environment variables it is a 
sound practice to append the new values to the current 
settings. 

Help Widgets 

Tiic Cl>K 1.0 help dialog widgets are true OSF/Motif widgets. 
The syntax and iLse model for programmers is the s^nnc as 
for everjr- OSF/Motif wiflget, whether ruj^tom or ptul of the 
toolkit. 11ns makes it easy for developers faniiiiar with OSF/ 
Motif programming to undei^tand and use help widgets. 

The OSF/Motif-based API directly supports various controls 
I [J manage an iustarice of a help dialog. Through standard 
OSF/Motif, Xt. and Xlib functions, progranmjers access help 
dialog resources and manipulate tiiese values as they see fit. 
Developers add callhanks (XtAddCallhackil), set and modify 
resources (XlSetVBiuesfn. manage and unmanage the dialogs 
(XtManageChild, and XtUnmanageChild) and free resources 
(XtDestroyWidgetil). 

The General Help Widget 

The general help widgt-i for CDE 1.0 is very similar to the 
general help widget in HV VlJE :J,0 help. It contains a menu 
bar, a Uible of contents area, and a topic display area. Added 
for (.'DE f aie buttons to the right of Uie t^ble of conteins 
for easy access to menu items. Behavior for tlie table of con- 
tents area fmd keyword searching has changed for CDE LO. 
Fig. 2 shows a genend hel]) widget. 
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Fig, Z. ( ienerai help dialog box. 

New Buttons. For convemence. buttons for the backtrack 
functionality, history, and hidex dialog boxes have been 
added to the general help dialog widget for CDE LO. 

Table of Contents. The table of contents area dianged signifi- 
cantly from its HP VllE 3.0 help system predecessor. The old 
vereion was a "here you are" tjije of listing, iirul it did not give 
the user tlie chance to explore other side topic^s unless they 
were direct ancestors of the cinreiU topic. C'onsequendy, 
this type of table of contents required the authors to write 
help topics witii extensive hyjx^rtext Unking lo other topics 
such as cliild topics that would be of direct interest to the 
user or direct descendants of the current topic. Fig. 3 shows 
the difference between HP M^E 3,(1 and CDE 1.0 table of 
contents boxes- 

CDE 1,0 help shows the topic, the subtopics related to the 
current topic, the ancestor topics, and Ihe ancestor's sibling 
topics. As the user selecl^ other topics from this table of 
contents, the listing changes so that it always shows the 
path to the topic-, tlie siblings of any topic in the path, and 
the children of the ciurcnt topic. Tlius, die wxiter otUy has to 
include hyix^rtext links to topics of interest if the topic is not a 
child of the current topic, an ancestor topic, or an ancestor's 
sibling. 

Another change is that the table of contents now displays 
graphics. Before, tlie table of contenls was limited to text 
Now, the table of contents displays multifont tind graphical 
headings. 

Searching for a Keyword, The search dialog for CDE 1.0 help 
ha.s l>eeu coniijletely redesipied. A conunon comt>lauit was 
that the old HP \TTE keyw^ord searcli dialog displayed or 
knew about keywords for tJie current volume only. 

Now I lie user hits the option to search alt known volumes on 
ttie machiHc f(]r a keyword. Since tiiis can be a titue-inteitsive 
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JTuji LeveF 
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Fig, 3. Help table of toiUenIs for (a) HP VUE 31) and (b) CDE 1.0. 

operation, the search engine allows the user to interrupt a 
search operation. Additionally, the user ran consirain the 
search lo a limited set of volumes. Fig. 4 shows tlie new 
CDE 1.0 search dialog box. 

Quiek Help Dialog 

Frcjni the progi'annner's point of %4ew, the quick help dialog 
is a stripped-do wii version of tlie general help dialog. Its 
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Using Help 

Haip organi;es iMoraaiiorv fnto topics, vou cnooie and display heJp topics in a 
help window 

Yoti can cKoofle « lo^lc in twtr w^yst 

• Select 3 MIe in the list of topic* at tht lop af the help window 

• Or, choose a hyperlink In Iha display area of the help window 

A ffypeflink Is an active word, phrase, or graplnic thai "(umps* In a related 
topic In a help window, any underlined te>-l I5 a hypeilmlf. A grey opon- 
cornered box identities a graphtc hyperilnK 

Hyperlinks Ido>; like Sh)s in a heip topic: 



r Sty re Manager Tasks 
Keyboard Shortcoli 




Graphic 
hyperfiriN 



To learn more about using Help, l\il\.. [his hyxi&rlink for a Nsl of topics 




Ftg, 4. CDE 1.0 help search dialog box. 



Fig. 5, t^uicic help dialog box. 

functionahty is the same as HP VLTE 3.0 quick help. It still 
contains a topic display area and a button box (see Fig. 5). 

Display Area 

F>oin the developer's perspective the help dialogs are treated 
as a single widget. Tliey are created, managed, and f lestroyed 
as one single object. K one were to Look inside one of the 
help widgets Ltiere would be not one monolitJiJc help entity 
but two separate very distinct components: the text display 
engine component and the widget component. 

The display engine component, as seen by the developer^ is 
the region ui the help fidget that renders the ricU text aiid 
graphics tuid pro\ides hyperlink access and d>iiainic fonnat- 
t ing of the text. The fidget component consists of tlie OSF/ 
Motif code that makes it a v^idget and the remainder of the 
user interface, inchiding topic liienirchy, menu bai; and sui> 
polling dialogs (iirinit index search, and Iiistory). 

Display Area Text. The display area aEows text to be rendered 
using mimy (.iifferent fonts. It also allow^s for various tyjjes of 
text. The author ctm speeif>^ dynamic text tliat will refonnat 
according to the window size and static text tliat will not. 
For dynamic text, a setiuence of two or more spaces is com- 
pressed into a single .space juid intcnitd new Imes wiU be 
changed into a space. For static text, all spaces and intenial 
new lines aie honored. 

To Reformat or Scroll? Uliilc vertical scrolhng is accepted as 
necessary w!ien lielp topics are longer tlian the availal>le 
screen spare, horizontal scrolhng is not. Tlierefore, when 
users resize help vvuuiows, dynamic text is refoiinatted and 
figures are ceniered according to the new window size. This 
dynamic refonnatting on tile fly is seen as beneficial by the 
customer. 

Scrolling Supported. Even usmg tliese line breaking rules, 
sometimes tiic lines are too long to fit in the available space* 
For this case or when static text pushes the boundary of die 
display area, the help system gives up and displays a st roll 
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bar so ihai the user can see the infonnation without ha\iiig 
TO resize the window. 

Flowing Text The display area has the abiUt)' to flow text 
an>und a graphic. Thi^ is seen as a spac^«a\ing nieasure and 
highly desired functionality. Tlie graphic can be placed on 
the left side or the ri^u side of the display area and the text 
occupies the space to the side of the graphic (see Fig. 6). K 
the text is too long and does not fit compieiely in the space 
beside the ^rapliic. One text wraps to below the grapliic. 

European (One -Byte) Rules- For most European languages 
(including English), brealdng a line of text at spaces is suffi- 
cient. The only other line^reaking role applied is to hyphens. 
If a word begins or ends i^ith a hyphen, the hyphen is con- 
sidered a part of the word. If the hyphen has a nonspace 
before and after it, it is considered a line breakal)le character 
and anything after it is considered safe to place on the next 
line. 

Spacer and hyphens can be tagged by tlie author as non- 
breaking chaiacters. This allows the added flexibiUty for an 
author to demand that a word or phrase not be broken. 

Asiao ( I/I ulti byte) Bules. F<ir Asian language support, breaking 
a line of text oti a siiact^ is unatceptable since some multi- 
byte languages do not break their words with spaces (e.g., 
Japanese and Chinese but not Korean). With the Japanese 
language, the characters arc placed one after another with- 
out liny word-brealdng character, since each character is 
considered a word. There is also the concept that certain 
characters cannot be tlte first character on a line or the la^t 
character on a line. English (one-byte) characters cait be 
mixed with niultib>te characters r 

Given these considerations, line breaking for multibjle 
hinguagcs bods dowti to the following rules: 

1. Break on a one-byte space. 

2. Break on a hyphen if the chJiracter before and after 
the hyphen is no! a space. 

3. Break rni a onc-i>yte character if it is followed by a 
m 111 ti byt e char act v r. 

4. Break on a itRiltibyte character if it is followed by a 
one^bytc character 

5. Break between two multiliyie characters if the first 
chLU*ai'ter citn be the last t^htu^acter on a line, atid the 
other character can be the first character an a line. 

Rather than hard code ihf values of tliosc Japanese charac- 
tere that can't stail or end a line into tlie (.T)E help system, 
the message caliilogue system is tised. This provides a gen- 
eral mechanism for ar^y muJtibyte language. AH the localiz- 
ers are rc^quired to do is determine which characters in their 



Text Wrapping Example 

ySV This 1$ an e>;ampJe of text vvrappmg around a 
( *-j graphic When the window is narrov.', the t^^ 
will wrap down to under the graphic instead of aJJgmng 
with the text ne?<J to the graphic 



Fig. 6, JCxample of t«xt flowing ai r junsl n gmjilyic. 



language cannot start or end a line and loc^dize the appropri- 
ate NLS file. The file /\im/MlWn\$f%ntffmtjhU^ contains the 
values of those characters that are used for rale 5 of the 
line-breaking niJes. If this file does not exist for a given lan- 
guage, rule 5 is ignored and line breaking wiU occur between 
aity TWO multibyTe characters. 

One LibrarY for All locates. The help system uses th^ same 
lil)rar> for professing one-b>ie or multibjte documents, h 
intenialixes how many of the rules to use based on the SLANG 
environment v'ariable and the character set used in the docu- 
ment. If a docunient specifies an IS(3-LATIN1 character set. 
the display engine does not bother looking at Rules 3, 4. and 
5 or using multibyte sj^stem routines. Only when the docu- 
ment and the SLAF^G enwomnent variable specify' a multibyte 
character set are these rules and routines used. Thus impacts 
tlie access and rendering time (mirunially ) but allows the 
same library to be usetl in tlie United Stales, Europe, and 
Asia, 

Color Degradation. A feature of IIP \'TtE 3.0 that w^as strongly 
desired was tlw ability to degrade color images, llaxing to 
provide three different images for each of three types of files 
is not feasible because of disk use. Tlie color degradation 
algorithms i^>ed by the CUE 1,0 help system are tlie same as 
used by the HP WE 'IQ help system. For TIFF ( tif } Images, 
the HP image librarj^ forces the image to the proper color set 
depentiing on the display tyi)e. For X pixnups (.xpm), the Xlib 
routines take \he same approach depending on the display. 
This leaves the X window (.xwd) files to n\anipuiate. 

The task is to reduce an .xwd file from a ftdJ-color image to 
a grayscale image containing no more than the maximimi 
uuml)er of gray colors available. Tlte first step in tliis process 
maps each of the X Window colors that the image uses to a 
k;r;iysr<ile himinnsify value. This is done using the NTSC 
( Niiiiona! Television Siiuidards (■ommiltee) formula for con- 
verting RGB values into a corresponding grayscale value: 

lyminosity = 0.299 x red + 0,587 x green + 0. 114 x blue 

where red, green, and blue are the X window color values 
witli a range of to 255. 

The next, step is to coimt the number of distinct Imninosity 
values used by the image. The help system then determines 
how many limiinosity values to assign to each grayscale. For 
examjiie. if there itre 21 dislinct luminosity values and eighi 
gray cohjrs, then the first five gray colors w^ill represent 
tiiree luminosity values, and the last tiiree gray colors will 
represenl two luminosity values. Next, a gray color is as- 
signed to the luminosity values it will represent. The last 
step is to cl\ange the nrighial color pixel to tlie gray color its 
limiinosity value indicates. 

If ihe mmiber of distinct luminosity (^oltjrs is less thmi the 
numlu^r of gray colors being used, then the help system 
spreads out the color use. For example, If there are three 
distinct luminosity values and eight gray colors, then the 
HiNl, third, and sixth gray colors are usetl in tiie image, 
msieiid of using the first three gray eoloi^. This provides a 
rit h rontHLSt to the image^ 

If the system has to degrade the image to black mid white» it 
first calculates the grayscale colors using die luminosity 
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calculation given above. Then the Image is dithered using a 
Floy d-Slein berg error diffnsion algoritlmi,^ which incorpo- 
rates a Stucki error filter. 

Color Use, The user c^an force the help system to use gray- 
scale or black and white by setting the HelpColarUse resource. 
Tlie CDE 1.0 help system will also degrade an image if it 
cannot allocate enough color cells for the graphic. For ex- 
ample, if the Image uses 31 imique colors, but there are only 
30 color cells left, the help system will try to disjilay it in 
grayscale and if thai fails, the image will be dithered to ttse 
black and white. 

Run -Time Help Volumes 

Tlic flcxibiUty and power of tius help system are largely 
placed in the author's hands. With the CDE HelpTag markup 
language imd a creative author, very different and interestmg 
approaches can be taken with respect to presenting Lnfonna- 
tion to the enrl usen Documents can be nrgani;5ed in either a 
hierarchy with hyperlinks referencing ]he children at any 
given level or in the form of a network or web, with a Imear 
coOection of topics connectedviahyiierlinks to related 
topics. It is up to the author to explore the majty capabilities 
with respect to autJioring online help for thi.s system. 

Help Volume Structure. A help vohmie is a t^nlleetion of related 
topics thai form an online book. NormaJlyH the topics within 
a volume are arranged in a hierarchy, and when developing 
application help, tJiere Is one help volume per app I legation, 
llow^ever, for complex applications or a collection of related 
apphcations, several help volumes might be developed. 

Topics within a help volume cai^ be reference^} by luiique 
location identlllers IJiat are assigned by the author. Through 
these location identifiers help infoi-mation is referenced in 
the nin-time environment. 

Help Volume Authoring. The authoriT^g language for the CDE 
1.0 help system is Heh>Tag, This authoring or nuirkup lan- 
guage cot itbr-ms to a variant of the Standard Genendized 
Markiij) Umgiiage (SGML (ISO 8879:1986)}, wlijch is a sun- 
pie language consisting of about fifty keywords, or tags. 

SGML is a metalanguage used to describe the syntax of 
markup languages. In a sense, SGML is ver>' similar to die 
UNIX utility YACC in which the syntax of progranmiing hm- 
guages such as C is described in a fomial, niaclune readable 
format, SGML itselJ' does not provide a metJiod for attaching 
semantics to niarkup constructs. Tliat is, the equivalents of 
the YACC actions are not contained in or described by SGML. 
An SGML syntax description is known as a document type 
definition (DTD). 

Other examples of rtiark^ip languages described \ia SGNfL 
ine^lude IITTVIL (H>perTexi Markup Langtiage), winch is used 
for documents on the World-Wide Web (W^WW), DocBook, 
which is used for docmnentation of computer soft ware, and 
PClS (Pinnacles Component Information Standard), which 
is used for the exchange of semiconductor data sheets. 

SGML is a ver>- powerful markup description language and. 
as such, allow^s a great variety in the maikiip languages to be 
described. However, hi a typical apphcation SGML is used to 

' COTiatrinient rafar? la the trieafthy of an rtem For example, a hook can cantam chepiefB, 
Ehaipiers can contain sectjons. and sections C3n contain pafagiaphs. Iksts. and tables. Para- 
graphs can contain lists and tabJes, stnngs can tie marked up as pfope? nam^s, anEJ so on. 



descjibe a highly structured markup language with the con- 
cept of containment playing a large role.* Tlie concept of 
containment works very well for applying style to text be- 
cause text styles can be pushed and popped on entry to and 
exit from a container. 

SGML containers are knowm as el em en Ls- SGML elements 
are demaicated by the keywords or iag>s using tJie form: 



< keyword > text . . , text » 



< / keyword > 



where keyword is replace rl t^y the tag name, in SGML Icmis, 
tiie kejT^^ord mtikuig up the tag name Is known iis the generic 
identifier or Gl. The fonn <kevword> is known as the start-tag^ 
and the form </l<evword> is knowTi as the end -tag. An SGML 
element consists of tlie stait-t£ig and all the text or contained 
markujj up to and including the end-fag. For' example, a sim- 
ple paragraph would be marked up as: 

<P> ThiB is a paragrapli witli p being the generic 
identifier</P> 

The .syntax of S(jML is itself mulablc. SGML-conforming 
documents all stari with im explicit or miphcit SGML decla- 
ration in which SGMJj featiu*es are enabled or disabled for 
the document, the document character set is specified, and 
varioiLs parts of the SGML syntax are modified for the dura- 
tion of the document. For example, the default form of an 
SGML end-tag is left angle bracket, slash, generic identifier, 
and right angle bracket (< , /, Gl , >). For historical reasons, 
the fomi of an end-tag in HeljiTag is left imgle bracket, back- 
slash, generic identifier, right angle bracket (<, \ , GI, >). The 
chatige of slash to backslash in tJie end-tag opener is speci- 
fieci iti the SGML declaration for HelpTag, 

As implied by a previous paragraph, SGML elements may 
themselves contain other SGML elements. Depending upon 
the niiirkup described in Uie docmtient type definition, ele- 
ments can be recursive. 

Further, start-tags c;an contain attribute and value pairs to 
parameterize tlie starl-tag. For example, die HelpTag element 
< list> has an attribute to det ermine if the iist is to be an or- 
dered (nimiber or letter lal>el) list or an imordered (no label) 
list. Creating an miordered list in HelpTag is done with die 
fo 1 kmi ng nuirkup : 



< list > 


* item 1 


* item 2 


* item 3 


< \ liet > 


which generates: 


item 3 


item 2 


item 3 



To create an ordered hst (starting with Arabic numerals, by 
default), one w^ouid enten 



<list type=order> 

* item 1 

* item 2 

* item 3 
< \ list > 
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which generates: 

L Item 1 
2. item 2 
a item 3 

Td create an ordered list stating with iQjpercase Roman 
otunerais in the labels, one would enter 

< 1 i B t type -o rde t or d^ r^^rocms > 

* itean 1 

* item 2 

* item 3 
<\list> 

which generates: 



L 

II 



item 1 
item 2 
item 3 



Note that in the markup described above for list, the individ- 
ual list items are initiated with the asterisk symbol, In this 
case, the asterisk has been defined as shorthand or, in SGML 
terms, a short reference for the full list item maikup <item>. 
Without using short references, the unordered list markup 
given above as the first example woiikl look like: 

< liet > 

< item > item 1<\ item> 
<item>item 2<\item> 
<item>item 3<Mtem> 
<\llflt > 

The short reference map of the HelpTag document type 
definitton slates that within a list eleri\erU the asterisk char- 
acter at the beginning of a line is siiorthand for the list item 
start-tag, <item>, and for second and suhseijuent list items, 
also senses as the end-t^g for the previcnis lisi item. 

In HelpTag, the generic identifiers and attribute n^imes aie 
case-insensitive. Attribute values are case-sensitive for 
strings, but the enumerated values of those attributes with a 
fixed set of possible values are also case-irisensilive. 

To reduce typing when creating a help volume, Uie SGML 
features known as SHORTTAG ;ind OMITTAG are set; to the value 
Vis for the classic HelpTag df K^iment ry^je descrii>tion. Tl^e 
most noticeable result of allowii^g iliese features is the al>ilit>' 
to leave off the at tribute names when specifyutg attributes 
In a start-tag. For example, the markup: 

< 1 i St type-order > 
is equivalent to: 

< list order > 

According to the SGMI^ standard, the entnuerated values 
(i.e., order mid uroman), must he unique within an element's 
start-tag so the attribute nanu* ran be omitted witJiout creat- 
ing ambigiuty, 

Creating a HelpTag Source File. Cunvntly there are no SGML 
tools lor aiitliurini^ III IpTag tiociuiienls. To date, all HelpTag 
autfiuring has been clniu* ussitg the common UNIX text edi- 
tors such as emacs iuid vi. Tlie concept of short references 
has been used heavily to shiiplify the jirocess of atit holing 
tlie HelinVtg source at\d mmimizing the amount of tyjiing 
necessaix 



One hindrance to using SGML tools to author HelpT^ source 
code is that the markup language does not adhere strictly to 
the SGML standard. In particular, short references have l>een 
used aggressively to the point of requiring extensions to the 
SG^fL svTitax, Certain changes in the SGML declaration, 
while perfectly acceptable accoriling to tixe standard, are 
not supported by any SGML tool vendcw. 

To enliance the possibilitj^ of future use of SGML tools for 
authoring BelpTag source code, a sec^ond version of the 
HelpTag document type definition (DTD) has been created. 
This second version of the DTD follows the SGML syntax to 
the letter and makes no use of esoteric features of SGML 
This canonical form of ihe DTD is referred to as the formal 
HelpTag DTD. 

The tools descritjed here for processing HelpTag source 
code will accept docimients conforming to both the classic 
HelpTag DTD and the formal HelpTag DTD, A switch to tlie 
dthelptag script -formal determines whether a docun^eni is to be 
processed according to the classic or formal HelpTag DTD, 

The Semantic Delivery Language. The distribution format* 
chosen for L DE Lt) clumged from the format used m HP 
\TTE 3.0. The old format could not be used for CDE LO 
because: 

• The distribution format was known only within HP and then 
only t}y somt^ members of one di\isJon. The specification of 
this distribution format was tiever published or intended for 
publication. 

• The potential for growth using this distribution format was 
severely restrictecl 

• The help volume existed in several files, resulting in 
jiroblems such as losing one or more of the files during 
insi filiation. 

The njjiti nu- format of the CDE 1.0 help system is known as 
the Seniantic Delivery L^uiguage, or SDL SDL confomis to 
the ISO 8879: U186 SGML standard. The benefits derived by 
ntoving to this distribution fomtat are: 

• SDL is based on Sf iML, wMch is a siandard that is strongly 
supported arul recognized in the desktop pulilishing arena, 

• The format is publicly available. Anyone c^ui create a parser 
to produce SDL. 

• The growth potential of this public distribution fonnat is 
imbt>utided. 

• The resulting SDL exists in one file, reducitig installatjon 
problems for developers. 

The SDL language can be thought of as a halfway point be- 
tween the t>i)ical SCtML applic-ation, which ignores fcjrmatting 
in favor of des<'ribing the semainic content of a dm-ument 
(from which fonnatting is tcj be derived), and the topical 
page description language such as Postiscript'^^* or nroff, 
which ignores the semantic content of a document in favor 
of rigorously describing its appearance. 

lli^like typical SGML applicatiotis that break a document into 
specific pieces such as chaptenn, sections, and subsections, 
SDL breaks a dotimieni into generic* pieces known as blocks 
and forms, SDL blocks contain zero or more paragrafihs and 
sr)L forms contain zero or more blocks or other forms (re- 
cursively). Tl\e SDL block is the basic unit of format lit^g, iind 

• The file totmai of tha help files delivered tti customer!, 
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Mela informal ion 
Li SI or Identifiers llOIDSl 
Tahl^ of Styles and Semantics iT€SS) 
Inllex Enlrie^s llndejil 



Virtual Pa§e (V1RPAGE) 1 



<tf STRUCT > 



VirlJial Page 2 




<VIRPACE> 

< Head > c Head > 

hcFi»iii> 



Fi^. 7, The structure and elements 

of an SDL volume. 



liie SDL fonri is a two-dimensional array of blocks and 
forms, Hg, 7 shows the stnictiire and elements that make up 
an SDL volume, which is also a help volimie. 

Most elements in SDL have an attribute known as the source 
senuutlic identifier (SSI), which is used to indicate the 
meaning in tlie original source document (HclpTag hi t!iis 
case) of a particular construct that got converted into SDL 
markup. It is also used to help in the nu^-time formattiug 
process by enabling seiirches into an SDL styie sheet. 

The SDL style sheet mechanism, known as the table of 
semantics and sitjJes (TOSS), is alstj ^in element witJiin the 
SDL dociunenl, SDL Ijiocks or forms and then' constituent 
parts can contain a som'ce semantic identifier attribute and 
other attributes such as CLASS and tEVEL, which are used to 
match similar attributes on individual style elements in the 
table of semantics and styles, VVTicn the attiibutes of an ele- 
ment in the body of the docimient itiatch a style element it^ 
the table of semantics and styles, the >style sfjecifieation hi 
that style element is applied to the element in the document 
proper Tliat style sijeeifl cation is then inherited by all sub- 
elements where appropriate until overridden by another 
style specification. 

Groups of SDL blocks and forms are collected m the SDL 
construct known as the virtual page (VIRPAGE), Each virtual 
page corresponds to an imli\idual lielp topic. For example, 
the Help Tag elements chapter and si through s9 (subchapter 
levels 1 through 9) w ouki each begit^ a tiew virttti^ page. An 
SDL \1rttial page is self-coniained in that all I he information 
needed to format that page is contaitiefi in 1 he page. There is 
no need to formal (he pages preceding a virtual page to set a 
context for format Hug the current page. Fig. S shows an 
exampleofaVlRPAGE. 



For rapid access to help topics, an SDL file also contains an 
element known as the list ofUlpniifierH (LOIDS). Wien an 
SDL J1le is accessed and tiie vinual page containing a spe- 
cific identifier is requested, the nui-tune help viewer can 
scan the hst of identifiers to find the requested identifier. 
Each list entry contains a reference to the identifier it de- 
scribes and the absolute byte offsel from \\\v beginning of 
the vohune to the viriual page contahMiig i hat identifier. 



<P>This is a paragraph with a 
<KEY CLASS = ^'B00K" 

SSI-"TITLE">Book Title 
</KEY> in it.</P> 



(a! 



i 



<V1RPAGE ID^"MyCHAPTi:R" LEVEIj="1" 

DOC-ID="MYDOC"> 
<HEAD>An Example Chapter</HEAD> 
<BLOCK> 

<p>This is a paragraph with 
<KEY CLASS="B0OK" 
S SI= "TITLE "> Book Title 
</KEy> in it,</P> 
</BLOCK> 
</VlRPAGE> 

(b) 

Fig. 8 (a) Aji SDL statement (using SGML syntax) that define.^ a 
paragmph with a book title in it. [bj A VIRPAGE represeiiLatifJii of 
the par^raph in (a). 
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Since SDL virtual pag^ can be formatted independently of 
the preceding pag^, the information in a list-of-identiiiei^ 
entrj^ can be used to get directly to the desired page and 
formatting can begin at that point. 

Eacii of the entries in the list of identifiers also contains an 
indicator that tells whether the element concainiiig the iden- 
tiJler is a parcigr^h. block, form. \'iityal page, or any of the 
other elements that can carrj' identifiers. In the case of ^Ir- 
Dial pageSt the list-of~identifier entries also carn>^ an indica- 
tion of the page's semantic level (e,g., is the \Trtual page a 
representation of a chapter subchapter, etc*). 

Duplicating the level and t>pe information of an element in 
the Ust of identifiers Is a performance enhancement. Know- 
ing which identifiers in the list correspond to virtual pages 
and knowing the semantic level of those pages allows a hu- 
man-readable table of contents to be generated for a docu- 
ment by processing only the list of identifiers, avoiding read- 
ing ajid pju-siiig tlie full docmuent. 

Processing a HelpTag Source File. The dthelptag compilation 
process performs a numl?er of different tasks in generating 
the compiled run-time help ^'olume: 

• Syntax validation 

• Conversion from the authored form at to run-time format 

• Location identifier map generation 

• Topic compression. 

While designiiig and implementing the help volume compila- 
tion process, techniques for improving perfonnanre emerged. 
The objectives were to create a file tliat supported quick 
access and a small overall disk footprint. Fig, 9 shows the 
components Involved in the HelpTag compilation process. 

For run- time display, a HelpT^ source file must be converted 
into a form usable by the CDE 1.0 help system viewer. Tlii.s 
conversion process is often referred to as compiling or trans- 
laling the lielpTag source file. The output of the conversion 
procesji is a single file containing all the information (except 
the graphics) necessary to display a help topic. The graphics 
associated with a topic are lofi in theii- own files and are 
referenced from wltiim the CDE 1.0 help system nm-time 
format, the Semantic Deliver>' Language. 

The dthelptag utility, which converts HelpTag source code to 
SDL, is a shell script driver for the multiple passes of the 
conversion process. The conversion takes place in three 
m^or steps: 

L The HeljiTag source is read in and the first step in con- 
version to SDL is made. During tliis step side buffers are 

Run-Time Help Volume 

Graphics 
Files 



HP HelpTag 1,2 
Snifrce Ftles 



■tif 



HPHefpIaD 
Compiler 



-^ foo.sdi 



HdpTftpics 



Graptiics Fifes 
Fig, 9.T\\f^ HelpTag compilation process. 



created to hold references to graphics and hyperhnks 
outside of the cmreni document and keyword entries 
that will later be used to enable ke>"word searches of 
the document. The keyifv^ord entries correspond to an 
index in a printed book. Fon?v*ard cross-reference entries 
may cause this step to be executed twice for complete 
resolution. 

2, The keyi^ ord side buffer is sorted using the collation 
sequence of the locale of the document. DupUcate key* 
word entries are merged at this time. 

3. The SDL output of the first step is reparsed and exam- 
ined for possible optiinizations. Then the optimizations 
are performed, the ke^^vord list created in step two and 
the external reference information from step one are 
merged in. and the SDL file is preprocessed to facilitate 
fast nm-time parsing and display. Finally, the SDL file is 
compressed and written to disk. 

The optimization possibilities mentioned in step three are 
created when the first pass must make worst-case assump- 
tions about text to follow or be contained in an element 
when the start-tag for that element is encountered. If the 
worst -case scenario does not manifest itself, the resulting 
^SDL code will be suboptimal. The equivalent of a peephole 
optiniizer* is used to detect the suboptimal SDL and to re- 
place, where possible, suboptimal SDL with equivalent but 
simpler constructs. 

The compression mentioned in step three uses the UNIX 
compress! t) utiUtyj which is a modified version of the LZW 
(X*empel-Ziv and Welch) compression algorithm. Tlie run- 
time decompression of the help topic is performed via a 
library version of the LZW algorithm to avoid requiring the 
creation of an extra process with its attendant time and 
memorj' penalties. 

To preserv^e the random -access nature of \he help topics 
within the help volume, the volume is compressed on a per- 
virtual-page basis (Fig. 10). That is, each virtual page is com- 
pressed and prefaced with a single null byte followed by 
tlurec bytes containing the size of the virtual page in bytes. 
After compressing the virtuid pages, the list of iflentifiei*s 
nuisl be updated to reflect that all \irtual pages foOowing 
the compressed page are now at a new, lower offset into the 
file. UTien the nm-time help \iewcr reads a viitual page, the 
reader looks at the first byte of the virtual page and if it is a 
null byte, decompresses the virtual |>age starling four bytes 
into live i)age (the nu!l byte atid three byies for length 
occupy the first four bytes of the page). 

Finally, after all fhe %irtual pages have been compressed, the 
metainformation in the SDL file, including the list of identifi- 
ers, is compressed. Since for perfonnance reasons all the 
metainformation is at the front of the SDL file, compressing 
ihai infommiion must necessarily be an iterative process. 
After compressing the nK-tainfomiation. the offsets to the 
virtual pages in the list of identifiers must be updated to 
refiect: that they all are now at new addresses. When the 
offsr'is in I he list nf [detUifiers have been updated, the meta- 
inrormarioii imist he ivrnmpressed residtuig in new values 
for the offsets in the list of identifiers. 

* Jn this applicaibn. the peepholB □pfimizar fsads a small subsgctjon of a document such as a 
chapter or paragraph, and works on that portion m iscJatton from the rest ot tha document 
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Before Any Coiftpression Afl^; VJRPAGE Campression 



12G3Z7 Bytes 



<VSTBUCT> 

<IDndvPA€El 
Offsel = T2e327. 

<IOnd = PAGE2 
Offset = 126532. 

<iPrid3PAGE3 
Offset = 12^03. 



<SDLD{IC> 
<VSTRUCT> 
<L0IDS> 

OflsETt^ 120327. 

-cIDrrd^PAGO 
OHset^12£5n. 

<mrrd=PAGO 
Oifset = 1Z7it4 . 



195 Bytes 



<vmFAGEJd = PAGl1> 



cVmpAGEid^PAG€2> 



VIRPAGE 1 Compressed 
tQ 1B4 bytes 



VIRPACE 2 Compresseii 
to 1303 bytes 



23S1 Bytes I 




Fig, 10, The compression sequence for an SDL file. 

At some point while iterating through this eompression and 
update cycle, the result of compression viill be no reduction 
in size or. woree, an uicrease in size. If the result is no 
change, we are done and we can write out the final SE>L file. 
If the residl is an increase in size, a |jadditig factor is added 
after the end of the compressed metainformation and that 
factor IS added to tire offsets ui tiie list of identifiers. The 
iteration then continues, increasing the paddirig factor on 
each pass imtil the size of the compressed metainfonuation 
plus all or part of the padding factor stabyiaes. The first pass 
in which the size of the compressed metainfonnation plus 
zero or moie b>les of the acided padding e<iua]s the most 
recently computed offset for the first viitual page terminates 
the itei-ation. Tlie compressed metainfonnation plus as nmch 
padding as is necessary is then written to the output SDL Hie 
jind all the compressed \irtiial pages follow. 

Graphic File Formats. Complaints about the text-only nature 
of HP \T"Eheip 2.0 strongly demonstrated the tiuth of the 
adage that "one picture is worth a tiiousand words.*" The 
CDE 1.0 Help Systjem supports the following graphic fonnats; 
X Bitmaps 
,xwd Files 
,xprn Files 
TIFF 5.0 



After VIRPAGE and Meia< 
information Compression 



C[»m|iresses to 
21174 Bytes 




ViRPAGE 1 Camptes^ed 
to 1&4 bytes 



viTifAOE 2 Compressed 
to 1303 bytes 



viRPAdE 3 C(Hnpress«d 



Uqw the values in Offset' are incorrect 
So rec compress Tfte meta information af- 
ter subtracting 1CI2IB3 (12G317 -24174) 
fmm eacli value. 

The decem|iression< adfustment, end 
compression are repeated until no 
further change to the offset valines is 
required. 




Graphic Compression. UTule JPEG compression schemes are 
common for use with TIFF tiles, no compression was being 
used with the X graphical fonnats. After several complaints 
from authors about how much space xwd files require, the 
Iieip system was modilied to find and access compressed 
files. The author can use the UNIX compress(l) conmiand to 
comt>ress the graphic files. The help system decompresses 
tJie graphic file into a temporary file and then reads the file 
as usual. 

LTsing compression on X graphic format files can impact 
access time. For very large graphic onages cjr for a topic that 
uses many graphics, this impact can be noticeable. The 
trade-off between speed and disk space is one tliat the help 
volume author and application engineer must address. In 
most cases the best results, botii for performance mid disk 
usage, are gained by using JPEG -compressed TIFF images. 

Printiiig 

Ciurentiy, CDE 1.0 DtHelp renders only text to hard copy de- 
\ices. The printing solution for the CDE LO help system 
allows the user to piint a comprehensive table of contents 
and mdcx, complete with page numbers. When an entire 
help volume is printed, each page is numbered allowiiig easy 
cross reference fi:om the table of contents or index. This 
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Fig, 11, Sample loeaiiEed help window. 

fimctionaJity did not exist in the HP VUE 3.0 help system. It 
was developed for CDE 1.0, 

Localizatian 

The C'DE iX) help system suppoit.s authoring and displaving 
of online help itt virtually any Itmguage. The oniijie help m- 
fcjmiation can be authored and translated in either single- 
byte or niultibyt.e character sets, and all the components 
within iJie developer's kit are multibyle-sniart ami can parse 
and display tiie localized information. 

The help widgets use tiie user's Sl^NG enviromnent variable to 
deLemiine what lanjijuage directory to retrieve tlie refjuested 
help volume from. If SLANG =iapanese when the request to dis- 
play help occurs, th(^ witiget code will attempl to open the 
Japanese localized veraion of that help volmne. IT one does 
not exist, then the default version, which is English, will be 
used- 

When Ml authored help volume is eon)piled via IlelpTag^ the 
author sets ttie proper chai"acter set option. The character 
set information is used at nin time to determine the proper 
fonts TO use for (lis^jlaying the Icjcalized help text. The Help- 
Tag conipiJcr assumes a defaull locaJi^ ($LANG-C). CuiTently, 
because of the complexities involvcti only one nniltibyte 
character set per volume is supported (e.g., a Japanese-to- 
Korean dictiona!^- cannot be displayed). Fig. 11 shows a 
sample of a locaiiKed win i low. 



Parsing My hi byte Characters. To make dthelptag work for single 
and muJtibyle character sets without constantly checking 
for the length of the current chai^cter. alJ characters are 
converted to wide characters (wchar_i) on inpuL This input 
conversion is driven by a command line option, a HelpTag 
entity file, or the current setting of the locale. All internal 
processing of characters is done on wide characters with 
those wide characters being conv'ened back to multibyie 
characters on output. Single-byte character sets are treated 
just like nrultibyte character sets in that the conversions in 
and out alw ays take place. 

This scheme of doing ail internal processing on wide charac- 
ters has proven to be a very effective means for making one 
tool work for all languages. Tlie scheme did require imple- 
mentation of wide character versions of most of the string 
functions (e.g., strcpy, strlen), but those fimctions were aD 
quite straightforvv'ard to create. 

Localizing User interface Cempenents. The menus, buttons, 
labels, aiKl error messages that appear in help dialogs also 
support hiU localization to native languages. The help dia- 
logs read these strings from a message catalog named 
DtHelp cat. Various localized versions are supported by de- 
tault and included with the developer's kit product. For lan- 
guages not supplied, the developer must translate the mes- 
sage catalog /usr/dthelp/nls/C/DiHefpmsg and then use the gencai 
command to create the needed run-time message catalog file. 

Conclusion 

Building uj^on the strong foundation provided by the HP 
YUE :iO help system, the CDE 1.0 help system (DtHelp) has 
become the standard help system for tlie desktop of choice 
for the providers of a m^ority of UNIX systems across the 
w^orld. As more companies provide the CDE desktop, this 
helj) sysle^m will become c\ en more pervasive. 
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Managing a Multicompany Software 
Development Project 

The development of the Common Desktop Environment version 1 .0 
involved a joint engineering project between four companies that normal ty 
compete in the marketplace. 

by Robert M, Miller 



111 March of 1993 executives from iTR IBM, Sun Microsystems 
and USL (now Novel]) aniioujiced at a UNIF'ORUM confer- 
ence the COSE (Common Operating SoOw^ire Environment) 
initiative. Tlie purpose of the initial ive was to unify the 
IINIX'^' operatiJig system industiy in the areas ofilistributing 
computing (ONC, ONC+, DCE),* multiniedia technology, 
object technology, graphics^ systi*m maitagement, ^md desk- 
top t^clmology. U^ule there have been other attempts 1o imify 
aspects of the UNIX worlds COSE was different in tiiat it 
succeeded in producing results. CDE (C-onunon I^esktop 
Environment) was tJie first pronused deitverable of U)is 
initiative and after two years its completion was announced 
at UNIFORUM in March of 1995. 

CDE LO was a joint engineering effort, between HP, IBM, Sim 
Microsystems, at>d Novell that was aimed at producing a de 
facto ai\d de jure standaid in a critical and highly visible 
technology— the X Windows graptiical desktop. CDE 1.0 is 
about L2 million lines of source code and over a thousand 
pages of end-user, system-administrator, and software- 
developer documentation. Tlie jointly owned CDE 1.0 
source tree also contains over 1200 automated regression 
tests written in V. These tests were developed to test the 
CDE code base. 

The primarj-^ amis of all of the participants involved in 
creating CDE were: 

To end the many years of battles between the Motif and 
OpenU^ok"^* cfunps, which helped to fragment t!ie l^NDC 
indust r>' ar^d slowed the development of UNIX applications 
To create a single fiesktop stantiai'd thai woultl pro\ide a 
common look and feel for users, a connnon set of adminis- 
tration tools for system administrators, and a common set 
of desktop APIs for software developers (A list of these 
APIs is pro\1ded in A])pendix A on page 1 J.) 
To lay the foundation for the future evolution of the UNIX 
desktop in a w^ay that w^ouid meet the needs of tlie open 
systems market. 

The original goal was to take Hie best technologies from 
each of the four companies mentioned above ^-^ith roughly 
90% of the code coming from existing products and \(Bi\ 
coming from new^ work. .As it lumeii out this wiis not pos- 
sible, and tlie percentage is approximately tiff/o reuse and 
40% new code. 

' ONC is Open Mgtwort Computing and DC£ is Distribiited Campirting Enviranmam. 
' Openbok i$ Sun Micn^ystsni's X Window System toolkit 



This was truly a Joint engineering project between four large 
organisations, which reqtured a whole new software devel- 
opment Lnfrastructnre ajid many new prf)ct^sses. This project 
was also the eullision orh>ur different con><^i"ate cultures and 
stiuidards of practice cjh project management and software 
development processes. This article exaniines some of the 
challenges that needed to be smmounted, and the processes 
that needed to be created before CDE could be successful. 

History 

Tlie Odyssey of CDE began in the summer of 1992 when HP 
and IBM began exploratory discussions on the possibility of 
creating a standard L'NIX environment. In the months that 
followed they were joined by Sun Microsystenis and the 
UNIX Software labs (USL), which was later acquired by 
Novell The agreement between these companies to work 
together m;ii'ked the birth of the Common Operating System 
Environment (COSE) , and more specifically, the Conunon 
Desktop Environment (CDE). 

However, on the CDE side, agreeing to work together may 
have been the easiest part of the process. Deciding what 
technology fragments would be the starting point, what 
would be tlte minimum acceptable functionahty, and who 
was responsible for w^hat pieces took a signiOcant amomit 
of difficult discussion. As we worked througli these and 
otlier difFicidt issues it liecamc very t)b\ious that good com- 
municalion w^ould be what would make CDE successful. 
To facilitate this comnnuiication and to get things going, the 
fohowLng leaiiLs ( w ith a rep reset itative from each company) 
were established: 

Management. The management team dealt with contract 
issues and m^or allocation of resources flike ftuiding for 
localization). They were the oversight team and all other 
committees reported periodically to !he management team. 
Foniial project chec^kpoints w^ere presented to litis team and 
when necessary, they acted as the arbiter for other teams 
when a deadlock occurred. 

Proiluct Description and Requirements. Tliis team was the day- 
lo-<iay |»roJet t rnimagt ntcm team, handling issues such as 
staffing, technology' owTieiship, and Ijlentling tlie teclmologies 
offered from each company m the new L'lNLX desktijp. Tiiey 
were responsible for fimUng ow^iei^ for new or unplatmed 
work items and defining the content and scope of the project. 
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Process. The process team was the heart of the CDE project. 

It was the job of the process team to determine the software 
life cycle and defect tracking system to use and the mecha- 
nism for tracking and reporting schedule information. They 
defined the hard^^are configurations that needed to be 
exchanged betu^een each company. Their most chaJlengiHg 
task was to figure out how lo allow* access to a single, \We 
source code tree for each partner through their eoiporate 
firewalb without \1olatiBg securitj^ constraints. This team 
was essentially' responsible for creating a w^hole new set of 
policies that would aDow four engineering teams from four 
different companies to work together productiv*et>; 

Architecttire. V^liile the inteni was to use as much existing 
lecluiologj' as possible, it was important to determine how 
that technology" would be joined together and then identify 
w^hat new fimcUonality vi-ould be needed to ensure a cleai>. 
well-integrated desktops It was the job of the an;hitecture 
team to ensure that tiiese things happened and to ensure 
that indi\iduai component owners (jrovlded the minimum 
feature set required by each of the four companies. 

Standards, From the beginning it was understood that the 
CDE project would work closely with X/Open^-^ to submit 
design documentation and later specifications to help CDE 
quickly become an industiy standard, Tlie standards team 
was responsible for w^orking with X/Open and other stan- 
dards bodies to understand their needs and jnocesses and to 
ensure that we could present oiu' materials in a useful way. 
This teaiti also acted as a channel for feedback to the other 
CDE teams. 

User ModeL Each partner in the CDE project had a signifi- 
iiuU iniorest in defining the direction of the user nKKlel for 
the desktoji {i,e,. its look and feel), IBM had CI -A (Common 
User Access J and each of the other [Jitrticipants had been 
shipping desktop products with fully tiefined user model 
policies. The goal of this team was to resolve disagreements 
about the general user model, as well as deciding specific 
questions about component behavior and its level of integra- 
tion with the system. 

As this Or^t set of six tcimis began to intcraci mtd slarted lo 
deiii witJi the issues, it quickly became evident Ihai we 
needed more teams to focus on specific issues. Tlius, the 
following teams were added: 

Biiild* This team w^ls responsible for keet>ing tlie midti- 
platffHTU builds healthy at each site and making sme that the 
code was built successfully on a niglitly basis- 

Learnirrg Products. Tins team derideci what online help and 
iifin|ci>[ty III am I a Is wfHild be writ ten, wh(» would write 
manuals, what looLs would he used, the schedule for manual 
review, jukI so on. 

Performance. Tliose of us shipiJing large CNIX desktops hatl 
a wealth of exixnience which showed (he need to be very 
ntiudfiil of t)erf<jrniance issues em1y, when it was still po.S" 
Hil>le tfi correct | >erf onnanct^ prohh^rns. This wmn was re- 
sponsible for estai>lishing henclintiirks (i,e., itser i-asics to be 
measured), finding t>ottlenecks in the system using perfor- 
mance tools, and working with the individual compfmcnl 
ownei's to fix problems. 

Internationalization. Tliis team w^as responsible IVir guiding 
the di'\t*lrk|iiueni leanis to ensure that components were 



properly written so that they could be localized and that 
policies were followed so that the CDE code worked on all 
four piatfomis and followed industry -standard practices in 
this area 

LoDalrzation. This team managed the process of loeaUzing 

message catalogs, online help, and hardcopy manuals. They 
were also responsible for deciding on the subset of target 
ianguages- finding translators, getting translations into tlie 
source tree, and ensuring tltai the transladons were correct. 

Test This team decided on the test tools to be used, defined 
and implemented the test scaffold, and creaietl tjie automated 
and manual tests that w ould proA^e the quality level of the 

desktop. 

Change Control Halfw^ay tiirough the project, tiiis team was 
sei up n> ensure that changes were made to the code in a 
thotiglitful and controlled manner and that the appropriate 
trade-offe wexe considered. The change control team w^as 
Instrumental in ensuring that w^e were able to meet a viuiety 
of dehi* ery dates with stable code. In the final months of the 
project this team played a critical role in deiennining v%1iat 
defects would be fixed in CDE LO and what defects and 
design issues woidd be postponed until a later release of 
CDE 

Aside from these teams, many of the component oxvners set 
up small intracompany teams to better ensure that Ll^ey 
w^ere meeting the needs of the other pmlicipaixts. Exfunples 
of this were the teams doing the temiinaJ enuilator (DtTermJ 
and the team doing the desktop senices (like drag and 
drop) who held weekly telephone conferences to ensiue 
Uiat there was acce|>lance from the other partners on tiieir 
directions and implementation choices. 

All of these teams held w^eekly phone conferences and ex- 
changed email almost daily — especially the build and pro- 
cess teants. Communication w^as the most difficult part of 
tills project. Despite the fact thai we spent cornniunicaUon 
resomtes lavislily, cfjuununicalion breakdowns were the root 
cause ot many of the misuncierstanclin^s aiui functionality 
problems that arose during the course of the project. 

Some teams wcjrked better than others. For example, the 
tJroc:ess team worked extreniely w^ell together throughout 
nuit*h of the t^roject, w-hereas the test te?am seemed to Juwe 
more tlian its share of problems. Partly, litis wils tau.sed by 
the sheer enormity of the test team's task. Tliey were faced 
with Ute challenge of creating from scratch a whole test 
scafftjld iUid infrastnicture that would meet the needs of all 
four pfulicipatu^g companies, Utiile API testing is a relativejy 
straightforwai'd process, testing GUI clients is not. Also, the 
test team was in the mifortunate siiuaUon of having to evolve 
processes as we went aiong w hich caust^d a good deal of 
rework and other problems, A discussion about CI IE Ti\sting 
is provided in the article on page 54. 

Tliose iemus tlial w<>rke<] best «iiti so i)ecaiise tiie individuals 
invt^lved had the titne to t^ome to some Ic^vel of trust and 
rcsiiect for each other. Tltey It^amed to seek a comnion 
grrjiuid tmd attem]>ted to present a common position lo the 
niher cnnunitlec^i. A surf^tisJjig hut sigjuficani jirohleitr fnr 
?^everal learns was ihe amtiunt of iMiiployet^ nimov(^r resiilting 
from I'eassigntneiits aitd resignation. This always caused a 
team to go througii a resets which was very time-consimiing. 
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New Processes 

Some of the in(li\iduals in eadi partifiiiatlng cf jmpaiiy were 
veiy devoted to tlieu' own biteniaJ processes. Thus, iii creat- 
ing new\ joint processes for CDE we often faced severe inter- 
nal resisraTire from the erij^inecring teams al all sites. This 
was pailly liecause we were all operating undey veiy tighl 
sche<.iules imd didn*t have the time to cope with new ways of 
doing things. Another factor was that, not only did the teams 
have to leam new processes, but they also had to defend 
these new processes within their oi^aniaations. 

By the enf! of the projecl we dui evolve an effective method- 
ology for implementing new processes aeross all four com- 
panies. The first step involved communicating to everyone 
concerned (engineers, project managers, etc.) tlie new pro- 
cess and why it w^as selected. This was done wx^U in advance 
of wlien we wanted to implement the process to allow for 
yuesiionJ:! and issues to be raised at all levels and IV >r the 
process to be tuned if needed. Lfiter the process team per- 
sonally visit e<:l and got accept^mce from all of the project 
maiiagers so that they would cooperate in implementmg 
fand enforcing) the new process. Finally, it usually mvoJved 
some degree of follow -up from llie process team to niake 
sure that the teams were fully engaged m tlie new process. 

A Single Source TVee 

Tlie time available to accompUsh the project was incredibly 
shoit, aiid the split of teclmologies was veiy intercomiected 
so that it w^as not possible to w^ork separately and make 
code deliveries to each other. We were all dependent on new^ 
functionality being created by the other teams and needed 
thai fimctionahty to fulfdl oim own objectives. Also, all of 
tlie partners wanted to be on an equal footing with regard to 
access to the source tree. It wiis conceivable that people 
coukl be working in the same areas of the tree s(3 we had lo 
prevent nndiiple people from working on the same code at 
the same time. 

We agreed that we w^ould put togt^ther a single shared source 
tree t hat would be live, hi that when i-m enghieer checked 
out a file at Sun Microsystems, it was immediately locked to 
all of the other paitner sites. The m^joi' obstacles to imple- 
mendng this were our corporate lire walls atid the band\^idth 
betw^een our sites. After significant research (and a lot of 
help from our respective telecom depaitments) w^e put hi 
place a frame relay system between all sites. Tliis gave us Tl 
(L544 MI.>its/s) bandwidtlts. Uliile it took a long time to ac- 
qiiire the hardware aiui work tJie issue througli om' viirious 
coip orate security deptirtments, the effoits ptud off liand- 
soniely^ This was a critical key success factor that really 
enabled John development between the various ctmipimies. 

To overcome the firewall problem wt created a separate 
suspect network at Corvallis whic h had a single rnacJune on 
it. This machine w^as the keeper of the golden CDE bits. This 
machine was set up to only allow UNIX socket comiections 
from four specific machhies (one from each site). A daemon 
%vritten hi FerP ran on I his machine and liandled HCS (re- 
vision f'omrol system) requestJi; coining in from each site, Al 
each pailner site a series of Perl scripts were written which 
wrapped the RCS functionaUty. When an engineer did a 

' Pari fPracUcal Eirtrsctitm fteport language) is a UNIX programmmg language desiped to 
handle system admintstf]ator functions: 



checkout, the request was funnel ed througli anollier firewall 
machine to the CDE somct^ machine, whicii did tlie appro- 
priate checkout, encrypted the file, ami sent it to the re- 
questing machine where it was deciypted and deposited in 
t!ie apt>ropiiate ctu'cctory. Each niglit the CDE som'ce ma- 
cliiiie created a tarball of the entire source tree and passed it 
along to each partner site where it was built. 

Each of llie pariicipating compajiies provided apjiroximafely 
six machines to each partner for build mid test puqjoses. 
Eve [7 night each company built on all four platforms. Each 
comimny had to develop significant expertise in developing 
softwaie on multiple iilatforTiis. This simultaneous cross- 
platform development was not only a necessity, but also 
very expensive. As engmeers made code changes they were 
required to buiid and run the new code on ah fom' platforms. 
Thus, it took a long time to make changes to the code and 
check it in. Tlie advantage, of coui'se, was that by ensuring 
rliat; the code always ran on multiple |>latfoniis, we didn't 
find oui"selves m a situation where we had to redesign and 
rewrite functionahty at the end of the project to work within 
different operating system configui'atiQns. 

Decision Making 

It was clear from the beginning of the project tliat we would 
not get anyv^ here if we used a r ojisensus model for decision 
making. Therefore, we de elded 10 use essentially the model 
creaie<i by t[>e X Consortium. In this model a representMive 
from a single company became the architect for a tecimology 
(e.g.. Motif toolkit) and was res]>onsihle for designing, docu- 
menting, anfi creating a sample iniplementation of a compo- 
nent or Iibraiy. Althougli the archil ecT was required to be 
open to input for requirements ai^d needs from the other 
pariicipantB, tlie final say regarding that technology was the 
responsibihty of the architect. 

Tills was the mf.Kiel we agreed to use and in large part we 
were successful at using it. However, there were times when 
we ran afoul of tliis process ami tJie teclinical decisions of 
component o\^mers were challenged by one or more of the 
other paiticipants. These chaUenges often were escalated aU 
the way up to the management team where, because they 
were thstanced from tiie technical problem at hand, it look a 
sign ifk ant amomit of time to work through the issties. ll 
was recogni/.ed by all parties that fiituie eftbits would make 
better progress by defining a single point of authority for 
making final, binding nilings on technical issues. 

Scheduling 

Wlien the COSE initiative was announced, the schedule for 
the CUE project Wiis also announced. This schedule was 
intemled in be ver>' aggressive imd also reflec^ted the initial 
assmiipdon that 90^j of CDE would be existing code with 
only 10% new code. The reality was that the melding of the 
teclmologies from each of the ]3aiticip;mts requu'cd extensive 
rewrites iu iiumy aieas. Also, the fimctionahty was somewhat 
fixed since none of the participating companies felt I bey 
could end up with a desktop that was less hinctional thai^ 
tlie ones they were currently shipping. 

Staitmg witli the desired end pomt, Oie process team created 
a scheciule that had alpha, beta, and code complete mile- 
stones followed by a llnal test cycle. We neetled to define 
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exactly what each of us meant by these niile^ones in terms 
of functionality', defect status^ localizatioit status, and 
branch flow coverage. We created checklists for component 
owners to fill out and attempted to normalize the data we 
r^cehed from indi\1dtial project managers. 

These first scheduling efforts were flawed for a numt>er of 
reasons. The first wa^ tfuit i*<»<jnlinating the elTorLs of four 
different companies wbb vei>^ time-constmiing. Second, we 
were unprepared for the s(^opc of new processes we would 
have to put into place and the aniouivt of time it would take 
to implenient ihem. hi some cases we made the classic soft- 
ware management error of tr>ing to legislate the scheduJe. 
functionality, and effort with predictable bad results. 

We eventually understood tiie kind of overhead we were 
dealing with ajid were able to create a \iabie schedule tliat 
was vmiKi to good effect. 

Conclusion 

There were htmdreds of ^pects of the CDE project that 
could liave t>een discassecL Only those issues which in retro- 
specf .scented most important have been disciissecL Panlci- 
pating in a multiconipariy joint development projec! is a ver>* 
challenging affair. It requires a willingness to rethink all of 
the familiar softwaie development processes tmd tools and 
to conie up with new solutioiis fiom both management iUid 
engineering teams. It requires an open mind in listening lo 
what each participant is saying since they nuiy use the satne 
terms hut \^itli different contexts and meanings, Tlie hnpor- 
t^ice 4jf f^onummication at all levels cannot be stressed 
enough. Taking the time to hiiilil i>ersonal relatioitsbips at all 
levels will pay back dividends over the life of the project. 

In the best of circumstances, the work beiitg done by the 
other partners must he f:onstajnly monitored to minimize 
misundei^riin{ lings, ensure that c^ommitmenls are being met^ 
and help shape the uievitable trade-tiff decisions that occur 
during a (project. Also, it s important to plan for the fact tiiat 



disagreements and escalations will h^pen in the mosi ami- 
cable of projects. %1tile tl means some loss of control creat- 
ing a neutral single point of authority for rest>lving these 
escalations will save enormous aniotints of time and help to 
preserve the necessar>' good wiU between the participants. 

h s natural to tmderestiniale the time it will take to tnil new 
pnx"€'sses in place, to deielop software on multiple t>lat- 
fonns, and to cunmmnicate and work out issues with joint 
development p^irticipants. This tendency to underestimate 
joint project o\ erhead mil also appear in individual engi- 
neer's schedule estimates. Of cours*^ it is absohUely neces- 
sary that the engineering teams have the opportunity to 
resolve ovmership and functionality and do a bortont-up 
schedule that can then be discusse<l in terms of trade-offs 
of functiomility, performance- iuid other features before the 
project scltethile is decided upon. 

hi most cases the work ^^ill be done by engineering teiims 
fiom a variety of geographic locations. Isually these teams 
do not know each other — except as tJie conipetinon. Yet 
they will need to work productively together to make each 
other successful. It will ill most always be worth the lime and 
money to bring tlie teams together face to face to build a 
relalionslnp that will prevail tlu-ough the inevitable tensions 
of a joint development project. 

Finally, it's important to realize that, desi>ite the problems, 
joint development can be clone. f-\mher. because of the 
diversity of experience and abilities of the different partici- 
pants, the end result will be richer and appeal to a broader 
set of custonun'S. 

HP-UK 9/ and 1 Q.D for HP 3O0O Serfes 700 aod BQO cornputers are X/'Open Company UNIX 93 
branded prnduc^ts 

UN^X IS a re^tster^d trademark in the United States and athsf countries, Jicansed eKcluslveCv 
thfough X/Open Cainpanr Limttid 

xyOpeo IS B FegfStered trademarlt and the X device is a trademari( of X/Open Compgnv Limiterf 
m ihB UK and other countrr&s 

OSF. Moiif , and Open Softwars Foundaiion are trademarits ol \h^ Open Software Foundation in 
thaUSA andotharcDLititnes. 
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Design and Development of the 
CDE 1.0 Test Suite 



Testing a product whose parts are being developed in four different 
environments that have different test tools end test procedures requires 
setting some rigorous test goals and objectives at the beginning of the 
project. 

by Kristaim L, Orton and Paul R. Ritter 



The Common Desktop Environment (CDE) test team was 
given tlie challenge of designing and organizing the develop- 
ment of an automated regression test suite for CDE LO com- 
ponents. Tills project contained all the usual problems in- 
volved in designing and creating a test suite for a lajge ajid 
complex desl<top en\aronnient. plus a munber of challenges 
that caine up because the development was a joint projecl 
between four different companies. The article on page 50 
provides some l^ackgroimd about the creation of the CDE 
project and the foin companies uivolved. 

Several goals for the tests were developed early m the pr<:jject 
that influenced the design of the test suite, the choice of 
software testing tools, and tlie implementation of the testing 
process. The rationale for some of tliese objectives will be 
developed in more detail in later part^ of this article. 

In setting the goals for the lest suites, we determirted that 
diey had to be: 

• Easy to develop. Tliere w-asn'i a lot of time in the CDE 
schedule. 

• Robust. Tests shouldn't stait failmg because of a nunor 
\Tsual change, a different font selection, and so on. 

• Reliable. Tests should iind the defects located in the code, 
but they should nol repoil a defect W'hen there isn't one. 

• Consisteni operation. Even I hough lour tompmvies would 
he developing tests, individuals at each compajiy had to be 
able to run the entire test suite, not just the fjatt.s wHUen at 
their own site. It was not acceptable to n>ake someone leani 
four different ways to run tests. 

• Consistent design and implementation. At the end of the 
joint development, pei^sonnel at each site wouid get engi- 
neering responsibility for the whole suite, including those 
portions written at other companies. It w-as impoitant that 
the tests be written such that an experienced test engineer 
at one company could easily luiderstancl the internal work- 
higs of the tests writlen at otlier sites. 

• Portable. The test suite not only had to run on each of four 
reference platfonns (one from each company), but also had 
to be easily ported to other nonreference platforms. 

• Maintainable. The test suite was not just tor the CDE LO 
sample inipletnentation. hut Wiis lo be die basis for eomptmy 
products or later versions of CDE> It had to be relatively 

• After the sample implemencatian af CDE, each participating coinpanv was enpiected to go off 
and preducti^e Lt^eir ovyn CDE desktop. 



painless to update the tests if they had defects, enhance the 
test suite for new fpneliqnaiity, and so on^ 

CDE Components 

The CDE components were the sofTware under test (SUT) 
for tliis project. From a testing point of \4ew, CDE compo- 
nents can be divided into tluree types: CDE API (apphcation 
programming interface) components, CDE GUI ( grapiiical 
user interface ) components, and graphical API components* 
CDE API components have no effect on the desktop, that is, 
no visual impact. An example of a CDE API component is 
the ToolTalk^' APl^^ CDE GLl components present desktop 
giapliics that can be manipulated by the usei; resulting in 
graphical changes on the desktop. Exantple^ of CDE Glfl 
components are the file manager and the icon eciitor. Graph- 
ical API components consist of a library of functions like a 
staJidtu-d APh except that calls to these Iiinctions usually do 
result in visual changes on the deskto[j. Examj)les of this 
type of CDE component include the DtHelp library and the 
DtWtdget library. 

Tools, Utilities J and Environment 

This section describes the tools selected for the test suite^ 
t!ie utilities created to augment the tools, and the structure 
of the lest implementation and operating environment. 

Synlib 

The Synlib API was one of the most hnportant tools used in 
the deveIo]7ment of the test suite. Synlib is a C-language 
hiterface that provides a means to simulate pragranunatically 
the actions of a user witli a GUI. It also contams fealures 
that allow the test program to monitor the state of the desk- 
top, such as watching for windows to appeal' oi' disappear, 
checking the tit le of a window, or checking other desktop 
features. 

Synlib was used to develop ail the tests that requhetl eit her 
manipulation of objects on the desktop or verification by 
checking the state of objects on the desktop. This tiuned out 
to be the majority of the tests. The CDE test team chose 
Syrdib as the GIT test tool because: 

TooUatk is the m^saging systein im^ by COt 
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• Synlib is portable. The only requirement for using Sjiilib is 
that the server be equipped with either the XTEST or the 
XTestEjctensioJil extensions.* which are used by Sjitlib to do 
such things as sunulate keyboard and mouse events. SviiMb 
was functional on aH partner systems, 

• Synlib is unencumbered. Synhb was developed at HP and 
w^as made a\^abk in source code fomi to each of the CDE 
partners without charge, 

• Test de\'elopment couid begin immediately. EIngineers could 
begin writing tests based on the components* specifirations. 
Since Synlib is not a record'and-playback method, a func- 
tioning CDE component is not required for initial test 
development. 

• Sv-nhb reduces dependence upon image capture and com- 
piuison. Many of the earlier tools for testing GO components 
use a method lliat depends hea\ily on capturing correct 
screen images during an initial phase, then comparing that 
image to the screen in a later tesr nin. Experience shows 
that this method is quite fragile and likely to produce many 
false failure reports. W^ith S>Tilib. other ways of checking foi' 
screen state make the need for image captme and compari- 
son much less important, 

• SjTihb contains a feat lire that allows position independent 
manipulation of desktop Items. A special data file called a 
focus m,ap is created that defines the keyboard traversal for 
setting focus to items ^^ithin a ^'vindow (Fig, 1)."^''^ With the 
focus rriap, the teat program can set the keyboard focus to a 
particular button or text field without needing to know its 
physical location in the \^indow, Since the focus map is a 
separate data file that is read by the test program, changes 
in the component tliat result in changes in the tiavei-sal 
order can be in coip orated into the tests by editmg the focus 
map file. Recompiling the test is not necessary. Suice the 
focus map file is platfonn independent, there only needs to 
be one focus map file per platform. 

Items that cannot be reached by keyboard traversal need a 
position. S>iilib features the concppt of an object file. This is 
a sepai'ate data file that defines locations (x,y pairs) or re- 
gions (rectangles) relative to a window origiri (T^g- 2). The 

" XTest and Xt^tEirrifnsJDnl are indusTrv^stanrtartt exiensium lo tha X Server, which allow a 
cllsjit access to sefvaf inforrrvation. 

*' Keyboard focifs is the temi used fa describa which of possiblY several objects m a window 
will T&zelvQ the results of fcGystrcik.es _ Far exajnple, a Motif uujndow may have Shree ffiffereni 
im fields, and the field that has the keytffiard focus wifJ get the tharecters typed hy the user 



mouse pointer can be tlirected to an item by referring to its 
location defined in the object file, .\ny change in a compo- 
nent that changes locations requires that the object file be 
edited, but the test code remains position independent. Also, 
since ihe locations vao' somewhat for each platform* there 
needs to be one object file for each platform. 

The Synlib test tool is described in the article on page 62, 

The Test Environment Toolkit 

The test environment toolkit (TET) was chosen as the test 
harness for the CDE test suite. C-language or shell-based 
tests were installed in the toolicit and nm using the toolkit's 
utiMties, TET is maintained by the X Consortium and is avail- 
able in the public domain* is |)ortable aci'oss many platforms, 
and has a fairly lai^e group of users. In the X world TET is 
beconiing a de facto standard for test suites. 

TET brought two important pieces of functionality^ to the 
CDE project. First, it proviiled an API for joun^aling. wMch 
gave us a standard way to report test results. Tills was an 
important aspect in keeping the tests consistent becatise no 
matter wtiich site wrote the test, the results journal would 
ha\^e the Scune format and cotild be interpreted and sunmia- 
rized using tJie same tools. 

The second piece of functionahty provided by TET was a 
mechanism whereby tests could be collected intn groups 
(called scenarios) and run as a set with a suigle conmiand. 
Since t!ie complete test suite for CDE contains literally thou- 
sands of itidi\idual tests, the ability to run a batch of tests in 
a sirigie step was essentiak 

Test Framework 

The selection of TET as the framework toolkit foroitr test 
enviroiimem meant that \n e har I tu choose a specific si I'ltc- 
tiu-e for otir test tree. This gave us a starling point for build- 
ing our test suite and pro\icied a logical structure that was 
expandable and at the same time, robust and maintainable. 
Hg. 3 shows our test framework. 

L-ocated at the root of the tree were the test and environment 
configuration scripts and libraries containing commcm APIs. 
These utilities anfi libraries were availaljlf for use by all of 
tlie test stdtes and, with a few exceptions (Synhb and TET), 
were developed jointly by the CDE test team. Each function 
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Fig. 1, An example of a focus 
nmp. Ft)r kf^yboard traversal pur- 
poses, the Motif clieirf can argn- 
\\YM* its objects in focus Jiroups. in 
this eKmnple there are thrf e 
fotnis groups. The fcjcus map file 
allows the test designer tfj ttame 
ti)e objects that caii rtv^ieivc- input, 
focus and define the correct coni- 
|] 3 nation of kf?y strokes (tabs and 
up and down arrows) necjded to 
shift the lixnifi from one object t to 
anotlier. Fnr example, tlie test 
designer can sperifV' that the 
Input fririjs Hliould bf rtinvHi U\ 
ohj(?f:t. MoiifGuiJhrflB.ButtonB vvlt.hout 
aiiy mformation about the location 
ijf the c5l}jeet. 
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Fij5. 2. All exaiiipie of an objecl file. 
Tlte test designer can ii&e the loca- 

Uan in th^ abjoct flle to set the 
focus to BiittOTi5 as is done in Fig, L 
However, if the Gl.n is redesigned 
and objecits are moved, tlie test wdii 
fail until l]rie object Me location a ;if e 
uptbted. 



mui binao' had to have, at a niinimiini, an associated man 
l)age describing its fuiictioiiality and tise. 

The following sections describe the test tree components m 
Fig, S as they were used for testing CDE 1.0. 

Libraries. Synlil> and DtTest aiT described in more detail in 
other sections of this article. Tlte tet_apj Hbraiy was modified 
sliglitly for oiu" envlronjnent, atiding code that alloM'Cd the 
tests to be run from a build tree. TJie area occupied by the 
build tree was not wri1:able by the test user, so any tests 
could not expect to tise that space for creating test nm data, 

UttltttBS. Tlie utilities were importiutt for providing a common 
way for tests to set tip and clean up their euvironmeiit. The 



bui[[l_scen script was used lo create a new TBT scenario fLLe 
by searching through the test files for tet_testiist sti\icttires, 
preventing (iie Ees!s and iheir assodated scenarios from 
getting out of synch ionization. The TETjounial flher 
searclied througlt tJie usually huge jotinial file and separated 
faihires atid their associated assertions, improving tlie efO- 
ciency of test result analysis. 

Dt Canfig, The scripts in the Dt Config directories contained 
euvironmeni variables used by TKT Hn/l Synlili and for satis- 
fying platfonn-specific envij*<jnineiU requirements. There 
was a conveiuence function in the DtTest library that set up 
glol>al pointers to these environment variables, making 
them accessible from any test. 
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S 6 Apri I I&S6 He wlett-Pac kard .loi i maJ 



)Copr. 1949-1998 Hewlett-Packard Co. 



The <ithf?r pieces of the tree are specific to each component 
test suite. A basic map of each coniponenl Itvf^ at the top of 
the tree, providing niaxinimii leverage for suites testing inter* 
client conunnnication and doing any Siysteni testing. 

Focus Maps. Each CDE component having a GO front end 

was tLMi^uired to pro\ide a focus map file that was aix-essible 
to all the test suites. For example, ilie calcutalor conipotient 
had a fiJe in tlie director>^ tiainetl dicalc.fm containing the key- 
hoanl frx^iis map for the calculator Gil, 

Syn lib Object Files. Each CDE component provide<i an object 
file contaiiiing aliases for the interesting x,y locations in its 
GLH. Since these objecrs were platfomt dependent and \ar' 
led greatly from platfonn to platfonu, cjbjeci files had to be 
generated for each of the reference plalibmis. 

Component Suites. Tliere was a subflirectonr' imrier comp^surtes 
for cat h til" I and Jibraiy in (T)E. For most suites, this was 
the top of the test tree branch^ For suites having funcdotiality 
Ihat was more complex than could be encompassed in one 
suite, tliis direclun^ contiuucd several subdirectories for 
better granularity of the covered fujictirinality. A go<jd exam- 
ple of this is the CDE help C(3tnponeni, which is made up of 
a help \1ewer and several /\l^ls. This suite was broken into 
four suIj.su ites with a top-level library and lest client that 
was accessible by ail suites (Fig. 4). 

Each test suite direct oi^ had a regimented stnicture so that 
I he suites could be efficiently maintiiincd m a consistent 
uianner At the same time, we Iried to pro\ide some flexibil- 
ity so thai creati%^* sohttions cotjld be engineered for the 
myriad of difficulties faced by the test-suite developers. 

Test libraries. j\s the test developers learned the test tools 
and framework, they found a lot of commonalties among the 
tests ill I heir suites. Th(*se Cf)nmu>nalities weie gathered 
into a c^omnion libraiy^ so they crniid be used l>y other tests. 
Some of these conunonahties iiu^luded the way tests were 
starif*d and closed, and the verification methods used on 
components. 



Test Clients. Xlany of the suites that rested tite CDE APLs used 
a test client to exercise tlieir code and verl^' tlwir assertions, 
For example, to test the subprocess c ontrol daemon, a cou- 
ple of chents w^ere developed to send and receive messages, 
verifying the v^dity of data sent at the same time. 

Ttsi Conftg. Like the Dt Config scripts described ai>ove. Test Con* 
fjg scripts set up environment \ajialiies that w en* optionally 
platform depejident and used by the tests. An asstjciated 
function was added to the test hbnMy to set up einironment 
variables as global variables accessible within Iheir tests in 
the same manner as that in the Otiest library. 

Test Focus Maps. The m^orit>- of the test focus maps imder 
tl\is subchreeton were used for defining tlie keyboard tni- 
versals of test chents. 

Test Synirb Object Files. Object Hies contain aliases for x,y 
locaiioiis in ij\ I r<imponents. Test develoi>ei:^ used titese 
Jocation aliases to dejBne areas in the GUI that needed to be 
tested for cut and paste and drag and drop operations and 
n^gions for image comparisons. 

Shared Images. A j though we encouraged test developers to 
limit tile nuniber of iniage comparisons. t!us method had to 
be used when validation w^as not possible by any otlier 
means. The next best thing was to reuse images so that 
more than one test could use the same image for verifica- 
tion. 

Tests. The tesB directory contained the tests arid other files 
that made up a tes! suite. A README file m the directory de- 
sc^ribefl the test suite strucrure aiui any special envu'omiient 
considerations tJiat needed to be taken into account wiien 
running the tests, Optiontilly, there w^as a directorj^ at the 
tof) level that contained manual test descriptions. The tests 
were intended for tests in which ^mtomaiion w^ls not feasible 
[e.g., tesUng the tuumatiiiu Itjok when a file was droppctl on 
a (irop site). 
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The test soiirce code lived in the tests directory. This direc- 
tory contained as many suhtiirectories as needed. Developers 
were encouraged to divide their tesrs into groups based on a 
component's f'linclionality, making it easy to determiiie 
which tests covered wtiich j>iece of code. This direct oi^^ also 
contajned an image direcloiy for images that applied to only 
one assertion and a data directory that contained validation 
data such as window tlljes and text for text comparisons. 
Tlie test output fljret torj' was a place holder used by the lest 
case controller (tec) at run time. The tests stored informa- 
tion about failures iti tJiese dii'ec tones and tlic test ease 
controller copied tliem into a results directory at run time, 
facilitating easy results analysis. The folio whig hsling is an 
example uf a typical test soiuce file. 

#include <DtTest.h> /* Dtl'est library header */ 
/* Forward declaration of routines */ 
static void tpl t ) ; /* test purpose one*/ 
static void startup U x cleaniip () ; /*TET startup 
and cleanup routines* / 

/* Initialize test environment toolkit data 

structures */ 
void(*tet_&tartiipJ { ) = startupO; 
void {*tet cleanup) () = cleanupO; 
struct tet_teBtli0t [] = t 

{ tpl, 1 ), 

{ ETULL, } 
>; 

static void startup () 



{ 



} 



DtTeStStartup ( ) ; 

DtTestGetTestEnv( ) ; 



Static void cleanupf) 

( 

DtTestCleartup^ ) ; 



static void tpl t ) 
I 

DtTestAssert (1, DT_ACCEPT | DT_REGKESS . 
"Assertion text here*'') t 
/* Code for validation of the assertion would go 
here » * / 

Dt Test Re suit ( TET_PASS, 

"As ser t ion passed,"); 
> 

Scripts. Many of the test suit45s used the test case controller 
niechanisni that allows the tests to define their own execu- 
tion tool This scnpL foimd in the scripts siibdirector^v did 
such tilings as H\m\ the component witli special opUony and 
set test-specific- envlronnieul variables. Additionally, a test 
developer coiUd define a separate script for test-specific 
setup and cleanup that was called from within tlie exectoo]. 

The DtTest Library 

Early in the CDE test development process, it was noted 
thai certain combinations of TET or Synlib functions were 
commonly used as a unit. This led to the creation of the 
DtTest library wMch pro\1rlefl a more efficient mechanism for 
accessing these units in a unlfonn martner. 

This iibi'aiy is a set of convenience functions developed to 
supplement the basic TET and Synhb fimctionahtj'^. Tliese 



functions provided an easier w^ay for test developers to per- 
fonn common testing practices ajid support the CDE testing 
metJiodology. Use of the DtTest library runctions also helped 
enforce internal consistency among tests developed at dif- 
ferent sites. 

lite convenience functions that au^'mented TET funcfionality 
niatie il easier !o print nu\ssages in the journal file, enter the 
test result, and control tiie opcrafion and execution of tests. 
The DtTest libraiy' provided an iiutialization antl a cle;mup 
routine iha! TET tiid not provide, and a way to get the values 
of tlie CDE environment variables. 

Fimctions to suppiement Synhb w^ere focused on two areas. 
One was to deal with text in a (JUI lext field or text widget, 
Kiuictions were written to place text, retrieve text, or re- 
trieve and compare text. The second area dealt with tech- 
niques for screen iniage capture, storage^ and comparison, 
lliese functions took care of miage naming conveniions, 
storing images, and sa\Tiig image analyses when image 
comparisons failed. 

The CMVC Defect Report Mechanism. 

The tests were programs, aiul like any set of programs some 
of them contained bugs. Often the delects were foimd not by 
the originators of the tests, but by other^ partners during test 
runs. Alter some unsuccessful attempts to keep track of 
defects and defect fixes \1a email and phone conversations, 
the test team started usmg the C'^ode Management and Version 
Control, or CMVC tool from IBM. Tliis nietJiod of report ing^ 
tracking, and verif>ing defects an<l tlxes was useti tor all 
CDE components. 

Code Coverage Tools 

Code coverage tools provide coverage statistics for a set of 
tests. They determined how^ much of the tested component's 
code was actually exercised during a test run. iVpit"*^ly 
tliese tools produce coverage statistics in terms of tlie num- 
ber of brmiches taken, the number of fimctions called, and 
so on. Tlie CDE test team needed to get coverage statistics 
since these metrics were one of tlie nieasmes of a test 
su i t e s CO n tp le teness. 

There wiis no single code coverage tool that was generally 
available to all of the CDE jjart ners, but each ha<l a solution 
that worked on dieir platform. Analysis of each of tlie differ- 
ent tools show^ed that they prodiiced results that were com- 
parable. The test team agreed tiiat all parineis would use 
their own code coverage tools to provide test coverage sta- 
tistics for their own component test suites. These metrics 
w^onld i>e provided at certain devTlopmental milestones to 
ensure that ade<inate progress was bemg made toward tiie 
coverage goals. 

Test Design Objectives 

Early iu ilie project, the test team adopted a set of tiigh-le\^el 
design oljjeclives. Tliese objecUves were based on the testing 
experience Uiat was brought to the project from the differ- 
ent partners. All hough team members from each company 
had considera])le softw-aie testing ex^^eiience. t he philosophy 
and testing metiiods used by each company were pften quite 
different. 
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The test team did achieve agreement on a number of basic 
objectives and goals, which insulted in the following high- 
level test design goais. 

Formal Test PLart and Test Cases. Each CDE component was 

required to hRve a formal test plan doeunieot, written by the 
test engineeis who had responsibility for that component. 
The test team pro\ided a template document (see Fig. 5). 
The lest p\m\ was %\Titten before test developmefit began. 
One of the sections of the lest plan containe<l a lisi of test 
cases for the component These test cases were based on 
the contents of the component's formal specification docu- 
ment- The rationale for this requirement was to get test 
<ievel opera lo pkui their components* test suite carefully 
before writing mvy tests. 

Assertion-Based Testitif . Tests had to be \mtten using an 
assertion verification methodology. With this method a test 
begins with a statement of functionality about the component 
thai cm\ be answered true or false. F(jr example. "Clicking 
mouse hurion one on the ciincel biaion will disntiss the dia- 
log box," or "Calling the OpenFite function to open file too In 
read mode will retiun error code NaSuchFiia when too does 
not exist." Following the statement of assertion in the test 
comes the code necessary to perfonn the action imphed m 
the assertion (e.g , cUck the cancel button, call the OpenFile 
function ), Code to \^eriiy the results of the action would 
report a pass or fail to the journal file. 

Testing Based on Component SpecifJcalEons. Tlie test team 
Jsirongiy encouraged that the design of the initial tests be 
based on a component's specifications. A component was to 
be treated as a l>laf k box until all the furulitinality described 
in tlie fonnal speriricaiiou <io<nmvent was tested. This ai?- 
proach ertsiired Uiat when a eornponent was out of phase 
with the spec ideal ions, an « imr wnuld iie reponed. Resolu- 
tion of the error soiTietimi^s uLijuii ij[)dating tJie specifica- 
tion, ensuring that changes would be captured in the docu- 
mentation. 

Testing Based on Code Coverage Goals. The test le^uu realized 
thai formal spt/cification tlocumcnts cannot cover every 
single detail, and thai a tesl si tile based only o\\ the dociuuent 
contents would fall short of achieving the test coverage goals. 
Thus, the team decided that alter tiie funct iouality covered 
in the specification document was incorporaied into tests, 
the test suite's code coverage wtjuld be measured, ff coverage 
fell short of the coverage goals, the code could be examined 



to deiermine how to design new tests that w^ould exercise 
code branches or fiincljons missed by the Initial test set 

Test Suite Completeness Based on Coverage Statistics. A com- 
poneni lesi suite would be considered complete when it 
tested all the fimctionality^ described in the spectfications 
and reached the niinimimi coverage goals set by the test 
team. The initial coverage goafs for all components were 
that 85% of all braiu-hes would be hit at least once, and 100% 
of all internal functions woukl be called ai least once. There 
was an additional requirement for API components that 
100% of all external (developer visible) functions %votiid be 
called at least once. Topically Ihest* statistit:^ v% ould be pre- 
sented as a triplet of numbers ( eg., 85/10()t/100). 

This was one of the goals that was revisited during the proj- 
ect, AltJiougb there w-as not total agreement In tlie test leatn, 
the n^ority felt that w-riting tests for GUI contponeots was 
more difficult than writing tests for nongraphica! API com- 
ponents. As a resuJt, the Gil coverage goal was low'cred to 
70% overall, with only 10% required in automated tests. 

Automated Tests. The ol>Jeclive w^as to create an aniomated 
regression i est suite. As the test plan oveniew document 
stated* "The expectation is that all tests aie automated and 
that only where absolutely necressai^' will manual tests l>e 
acceptable." Howeven as noble as this goal was, we had to 
low^er our expectations a bit. By the end of the projeci the 
test team was still requiring automated tests for the API and 
graphical API components, but for GUI components, tiie 
requirement Wtis that the automated tests pro%ide at least 
40% branch flow co^ erage. The remaining &>M branch cover- 
age could be obtained by manually executing tests based on 
ei titer the list of test cases in tihe test plan or m a separate 
test cbeeklisl document. 

Mifiimum ReMance on Screen Image Capture and Comparison. 
Experience witli aiiE<iniaie<l lestiiig oldeskioji coiuiHincms 
sluiwtHl tiiat test suites that relied heavily on .screen image 
capture iuid <'orni>;mson were found to be unreliable — diey 
would generate many false failures. The new Synlib lest tool 
contained features that could be used to verify a correct 
desktop state witiiout resortmg to comparisons to previously 
saved "golden" images, and the lest team aggressi\*ely inves- 
tigated and promoted these techniques. Its estimated that 
tjie CJ)E test suite contains less ihim liy% of tJie "golden" 
images that would be required if a record-and-playback tool 
liad been used. 



Common Desktop Environmeni 
FunctJQnaf Ver ifi^ation Test Plan 

1,0 fntTDdLfciiurt — Define tfie scope of Hie testing ^nif 
the comp[}neiirt& lasted. 

Z.0 Test E n vif onmenl — D ef i ne Itard ware a ltd soHware 
requiraiTiciiits. 

3.0 Test Matrix 

3.1 Test Si rale gy — Plan at attach, including the 
tunciionslity covered. 

3.2 Test Coses — List of lest cases, idemjivfng 

imaroparability, ItBN, Mress. and inierplatform 
tests^. 

3.3 Untested C^de 



Fig- 5. f)t.]ttine for a tesl plan. 



Test Development Process 

Once the tT>E test teani had straightened out the details of 
the testing framework and produced a set of guidelines for 
the t€st developers to folknv. it was time tcj implement the 
solution. We set up test goals for each of the component 
developnieni milestones. We jointly developed a training 
course flesigned lo get test developers familiar w^ith t>ur pro- 
cess and test tools as soon as possible. Lastly^ we set up a 
process for eacli of the members on our leatn to follow^ as 
we accepted the test suites for inconjoratioii into tiie CDE 
saniple implementation test suite, 

Each CDE component had fujtrtionally comj>lete, function- 
ally stable, fintl code romplere milestones. Kach of these 
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miiestones had test coverage goals as shown in Tatile I. .\n 
API would be lunctionally stable when it had 7M coverage. 



Table I 

Test Coverage at Component Milestones 

Milestone API QUI External Imernal 

I Breadth) (Depths 

Fimctionally 5(m 5t^/10% 9f)% 70% 

("oniplete 

70% 409fj lOO*^ 90% 



Fimctioiially 
Stable 

Code 
Complete 



85% 



70% 



mm 



100% 



' Five tests defined or 1D% coverage, whiehaver is greater 

Wlieii nieasimng the source code t'ovemge of a tesft suitet 
besides the base number of overall coverage (lines of code 
hit divided by d)e lotiU lines of code— die uimibers in the 
GUI and API columns in Table TJ, there is also a need to look 
at the external or breadth coverage. For an API, this was the 
number of extern cii functions caller I div jcied by die total 
number of external functions. For a GUI, diis was die num- 
ber oi' fiuictional modules exercised divided by the total 
number of modules (i,e., Were all the buttons in the dialog 
box hit?). Internal or depth coverage is the number of mter- 
nal (nonpul.JlicJ fmictioiLS called divided Ijy the HJtal number 
of internal functions. 

All components were expected to have a base level of auto- 
mated acceptance tests, but GlJLs could make up tlie rest of 
their test coverage through either automated tests or well- 
deluied manual tests. For some components, such as the 
frojit panel wliich had to test the animation of the subpanels, 
creating some scripts thai w(.:pu]cI be run by lumd and manual 
verification of the resultii was the best way to go, APIs were 
expected to pro\ide all automated tests. 

As components reached one of their milestones^ the test 
team representative from the company responsible for the 
component would check for more test development specific 
milestones. These milestones were put in place to ensure 
diat the test team's final protkict w^as a robust, maintainable 
test suite. 

The first item the lest team checked for at each milestone 
was a complete test plan. It was imi)ortant that the test plaji 
thoroughly define the testing to he done smce as a last resort, 
we would use the list of test cases in the test plan as a Ust of 
manual tests to complement die automated tests. 

Tire second task the test teaiti performed at the milestones 
was a review of the automated tests. We developed a criteria 
checklist diat would check for the following: 

• Acceptimce tests. The priority for die fund tonally complete 
milesKine was to have automated acceptance tests tliat 
could run in less than an hour. 

• Assertions, Assertions were checked to be sure that they 
described the component's fimctionahty^ aiKl clemly slated 
what was being tested and htyw it was being verified. Tliis 
was the hardest area for new test developers to leain and 
Oie hajTiest for us to judge. 

• Use of the DtTest convenience fiinctions. These fwictions 
were fieveloped to ensiu'e consistent jounialing of tests. 



error handluig, and naming conventions of image m\d data 
files. 

• Use of copyright notices and standard header files. These 
tests were done matuutlly for the first five or ten lests for a 
partictilai' component. The test developers were expected to 
use their "blessed" test suites as a template for tlie rest of 
their tests. 

• Test suites must rtm autonomously. TET allows for a ver>^ 
fme gratntlarity of execution, down to individual test pur- 
poses witlun one test e^ise. A test puipose is a function 
made up of an asseri ion, c otle validating the asseri ion, and 
code for reporting die result. Test purposes could be 
grouped together withiti im uwocable component, ensuring 
that they always ran together, but beyond that, tliese in voca- 
ble components always had to be able to run on their own. 

• Test-spc^cific libraiies and clients. These were reviewed to 
be sure that the librruy (ails were documented in a header 
(lie and test chents in a README file. 

• Portability. Tesis were reviewed for nonportable practices 
such as hai-dcoded path tuuues and x,y locations. The total 
nimiber of stored irtiages was ^liso expected to stay under 15 
per test suite. 

• Test Execution. Tests haft to run using the test case control- 
ler on ever>- platfonn. 

As the project wore on, dus checklist streteherl out to 77 
items and became affeeiionately kno^"^!! by the component 
engineers as the "77 points of |.)ain," Our last milestone item 
was to check that memoiy integrity was beuig checked. 

About halfway through the jjioject, test development efforts 
really got into full swing at all the companies. We all used 
temporary test engineers from time to tirne, and it weis nec- 
essarj' for the test team to get these new engineers familiiir 
with oiu- methodologies as soon as possible. We jointly tle- 
veloped a twrHo-three-day traunng course that new test 
engineer took before getting started. This covered tr^uning 
Tor the tools, how to write a good tissertion, and creating 
Imakefiles, By the third day, a test enguieer would have com- 
pleted at least one test and be familiar enough with the test 
ti'ee structure to get around without help- We used some test 
suites tliat were good examiiles of the kind of tests we were 
looking for, and we had an exaruple test suite as a guide for 
engineers to use for doing more coni|)lex fimctional verifica- 
tion. Final ly^ we developed a '1iow to" docimient tliat ai'chi- 
tectiu-ally describet! the test tree design and defined all of 
the tools and irUerfaces a\^ailable for use. Despite our best 
efforts, it still took about two to four weeks for a new test 
enguieer to develop the ability to do a cotiple of test cases 
per day. 

Test Execution Cycles 

Throughout the development of ODE there were severai 
piaces where we stopped and executed a conmion test exe- 
cution cycle m which all CDE partners participated. Tliese 
test cycles were driven by events such as conferences and 
trade shows, where the desktop was displayed, and mile- 
stone completion dates. We <le\'eloped a test repon form so 
diat the results could he compiled in a consistent fashion 
and results reported at each company. Journal files from the 
test runs were checked mto the tree so that it was easy to 
check for' both component and test regressions. After each 
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test cycle* we would dti a postmortem to improve the pro- 
cess for the next test c>-cle. 

Our finrt ^al in the te^ execution arena wa^ lo define an 
execution cycle thai would enable each company to execute 
ihe tests in a uniforni. auionialed fashion. The phases of tMs 
cycle are Listed t>elow. Phases four through ei^l were re- 
peated for each t€*st suite. 

Phase I Machine Setup. This included setting up the reference 

t>ialfornLs ai viwb company, taking into account any hardware 
or st>ff Wiire requirements documented in the test plans- 

Phase II Test Envirancnent Build and Instatlatton. l^iis was eas>' 
for us since our test trees were set up to build on a nightly 
basis in the same fashion as the source trees. The more diffi- 
cult jjart was tite installation. Since the test suites would 
certainly nui overnight, the build wouJtl interrupt the test 
execution, causing indctenninaic resuJts. The short-term 
solution was to turn off test builds diuing test cycles. For 
the long term, we wanted to create aii insiallation proce^ as 
aiUomated as the build jirocess. 

Phase \\[ General Test Envimnitient Configuration. This phase 
includefl defining configuration data and executing any 
setup programs, including: 

• Putting the general en\1ronment configuration defined in 
the Di Config files inio the test execution enMromnent 

• Setting up user permissions and scripts that musi be nm as 
root. 

Phase iV Companent Specific Test Environment Configuration. 
Aiuil<jgijus Ui the jDievious plutsc, during llii.s [jhase U^e com- 
ponent's test environment was set up, itK'lu<Hng: 

• Putting the (omponent -specific configuration file into the 
test exec lit ion c uviromnt^nt 

• Starling the session using the dtsession setup script 

• Running btiild.scen to create a current scenario file. 

Phase V Run Test Cases. The tests were execuieti using the test 
case conl roller, specifyittg an output diiectory for sa\ing 
restilLs and a journal file. 

Phase VI Test Results Evaluation. The joumal files were mn 
tlrroiijLjli tlir TETJomixal fiittn-stTipt In tlnd any test failures. 

Phase VII Component-Specific Shutdown. Between each test 
suite, the test envirunuienl wan cle^nJied up usin^ the same 
script m for setup. The session was stopped via the cleanup 
dtsession script to keep Ihe previoiis tests run s exit state 
from affecting the next test. 

Each company had to check their test results into the 
shaied test source tree al the end of tlie test cycle. They had 



to state for each component the t>pe of testing done (auto- 
mated or m^umal). the cuirent branch flow numbers, the 
numljcr of test cases ran (ntimber of test assertions), and 
the pa^fml status for the total run. A pc^tmortem was done 
after the te^t cycle, looking in particular for test suites that 
had different outcomes at the different companies. Defects 
were filed against the test suites and the components, and if 
a particular test cycle was targeting a release. Jhe defects 
were fbced and the tests were rerun. 

Sj-^em testing ivas done more sporadically. We developed a 

fairly extensive sj'stetn test plan covering areas of inierc»per' 
ability, 11 BN (iniematronalization). interplatfonn, mui stress 
testing. I iifortunately, these tests were never automated, in 
part because of a shonage of resources. These tests were 
more complex, and therefore more difficuh to automate 
thmi the fmictional tests. We did make sure that both inter- 
operability and IIBN fmictionality were tested witli each test 
cycle. We i;suaJ1y reliecJ on the CDE test team membei^ to 
manually nin tlirough the system test plan for their t^ompa- 
iiy s platfonn. For interoperability', a matrix was developed 
shownig the tjpes of interclient comn^uni cat ions that were 
allowed for each component. The IISN se<?tion described 
pieces of the component that used input methods for EUC 
(Extended UNIX ~ Code) 4-b>fte charactei-s as well as sec- 
tions that were expected to be localized. Our reference lan- 
guages were Japanese EUid German, so tlie manual checklist 
was mn against these two languages. 

Conclusion 

By tlie rime the CDE sample was done, some of the CDE test 
suite was not complete. Some of the components had no 
automated tests and some test suites were in various slates 
of completion. However, the existing test suites and tlie test 
frame wcnk t)rovicied a jimul basis for a maintainable test 
suite for the HP CUE product In lact, the iramework iuul 
methodologies have been expanded to encompass other HP 
prodiK^ts with a great deal of success. Work continues to be 
done in this area. atUiing further expansions such as intcnia- 
tionalized tests and other system testing. 

UWIX Js a regssie/ed rrademark in ihe United StaiBS arid oiher cauntnes, license e)(cf^s1velv 

through X/Open Company Limitacf. 

X/Open IS 3 registerBd trademark and the X device is a trademark of X/Open Comparfy Limited 

iiT The UK and Diimr countries 

OSf^ Mont and Ofren Software Foundation are tradenaarlts Qf itis Open Sottwera Fcmndation in 

the U S.A mi Dtivef countrtes 

ToolTalk IS a trademarti of negistered tradamark ot Sun MiCfosysterns m the U.S.A. and certain 
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Synlib: The Core of CDE Tests 

Syntib is an appiication program interface for creating tests for graphical 
user interface applications. A collection of Synlib programs, each 
designed to verify a specific property of the target software, forms a test 
suite for the application. Synlib tests can be completely platform 
independent— an advantage for testing the Common Desl<top 
Environment (CDE), which runs on the platforms of the four participating 
companies. 

by Sankar L. Chakrabarti 



Synlib is a Olaiiguage application program interface (API) 
designed l o enable tlie user to create tests tVjr graphical user 
interface (GUI) software. The user simply tells Synlib what 
to do and it will execute the user-specified testis on a vanety 
of f lis plays and in a variety of execution environments, 

A complete description of the Synlib API is beyond the 
scope of this article and can be found in references 1 
through 4. In this article we will only indicate fiow the ideas 
and capabilities supported by Synlib were applied to the 
development of tests for the Ciommon Desktop Envirojimeni 
(CDE J described in the article on page 6. An overview of 
CDE test technology including a description of the role 
playeci by Synlib can be fomitl in the article on page 54. 

To test GUI softw^are, we create programs tising the Synlib 
API, These programs in tmii manipnlate and %'eriry the ap- 
pearance and behavior of the GUI apphcat iiiin o\ interest 
(the target application). The recommended approach is to 
create many small Synlib programs to test the target soft- 
wme: 

1. View I lie target GUI software ivs a collection of imple- 
mented properties. 

2. Create a S^iilib-based program to verify each property. 
3* A collection of suc:h Synlib programs forms a lesl suite 
for the GIT sofhvare. 

With Synlib, the mabi task of testing GUI software reduces 
to creating the individual test programs. Considering each 
test program to be yoiu' agent, your task is to tell the agent 
what to do to verify a specific property of the program you 
wish to test. Assume that you want to test the following 
property of the front panel on the CDE display (Fig. 1): On 
eUcking flie left mouse bvtum on Uw slyle manager icon on 
the CDE JYont panel, the style inanagei'applieafion uyiH be 
kiuncked. ft is likely that you will tell yoiu- agent the follow- 
ing to \'erify if t iie jiropeity is valid for a given implementa- 
tion of tlie front panel: 

1. Make sure that the fi'ont panel window is displayed on 
the display. 



2. C.'lick the style tnanager icon on the front piuiel window, 
Aliematively, you rt light ask the agent to selecl tfie style 
juajiager kxrn on die fjont panel antl leave it lo tlie agent to 
decide how lo select the icon, Syidib supports botl^i alterna- 
tives, 

3, Make sure that a new style manager window Is now dis- 
played. If the style manager window is mapped then the 
agent should report that the test passed. Odierwise, the 
agent should report that tlie test tailed. 

Tliese instructions are captured in the foOowmg Synlib pro- 
gram. Ml function calls with the prefix Syn are pait of the 
Synlib API 

maiii(argc^ argv) 
int argc ; 
char **argv; 
( 

Display *dpy; 

int windowCount ; 

Wi ndow * wi nd o wL i s t ; 

window s tie 11, windpw; 

char * title; 

SynStatus result; 

dpy = SynOpenDisplay {NUIil^) ; 
re Bill t ss SynNaineWindowByTitle [dpy, 
" My Front P ane 1" , " One " , PART I AI._MATCH , 
iwindowCouEit , SwindowList) ; 
if (result =- SYN_SUCCESS) 
{ 
result = SynClickButton^dpy, "Button!", 

" Ky F r on t Pane 1 " , " s t y 1 eManager _ icon")? 
/* 

* In the alternate imp lenient at ion using focus 

* maps we could simply eay: 

* result = SynSelectltem {dpy, 

* "MyFront Panel", 

* "StYleManager_Icork_FocuaPath" ) ; 
*/ 

result = SynWaitWindowMap (dpy, 
" Styl eManager ",TIM£_OUT] ; 




Fig, 1- Front panel of the CDE (ifsktoi 



Style Manager 
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if (result ^= SYN_StrCCBSS) 
{ j^esult ^ SynGetShellXndTitle (dpy, 

"Style Manager", &shell_vindovir &title}; 
if Cfltrcmp (title, "Style Manager") == 
0) 
printf CTest Passed: Style Manager 
window appeared. \n^)i 
else 

printf ("Test Failed; Bsipected Styl« 
liiii^gfr wiadow; found ^aNn", titlej ; 
} 

else 
printf {"Test Failed; Expected Style Manager 
window would itiap but none did.Vn"}; 
) 

else 
printf ("Test Aborted: Front Panel window 
could not be found* \n"J ; 



} 



SynOpenDisplayO connects to the display on which the target 
apphcation is mnning or ^ih run. SynNameWindowByTit^el) de- 
termines if a window of the specified title (in this case One) 
IS already displayed. If so. the iiser (i.e., the programmer) 
chooses to name it MyFrontPanel. Throiigl\ SynCfickSuttonO, the 
S^mlib agent ts instmcted to click on the window MyFrontParel 
at a location called styleManager.icon. The agent is being asked 
to expect and wait for a \vindow to map on the display, Hie 
function SvnWaltWtndowMBp accomplishes the wait and names 
the window StyleManager if and when a windoi^' maps on die 
display. If the mapped window has the expected title, Style- 
Manager, rhten liie agent is to conclude that the test succeeded, 
that is, the front panel window had the specified property' 
(chcl<ing on the style majiager icon really launched the style 
manager appli cation j. 

In practice, the tests would be more complicated than this 
example. Nonetheless, this simple program illustrates the 
basic paradigm rr>r creating test agents. You need to name 
the GVl oijjccts t>r inlcrcsl and provide a tnef^btinisTu for tlie 
agent lo identify these objeci.s tliiring execution. The agent 
should be able to niaiiipulate the uimunl objects by deh%Tr- 
ing keystrokes or bud^m inputs. Finally, the agent should be 
able U) verify if specified I lungs happened as a result of pro- 
ceasing die dehverefl inputs. Synlib is designed to provide 
all of these capabilitit*s. Table I is a summary of Synlib's 
capabiiities. 

Platform Independence 

Synlib prograuis i an be wntten so that they are completely 
platfoj"m independenl , For examj>le, in (he i>rograni above 
there is nothing that is tieti to specific features nYn f)!atfonn 
or a display on which tlie target GUI ap[)lir;ition may be 
executing. All pjatfonu depejulent infomiaiiou ran be faxu] 
is encouraged to bej ai)siracteci away throiigli the ntechanism 
of sofl coding. In the program above, the statement using 
Ute function SynCfickButton is ;ui exiun|)le of sofl ct)ding. The 
last parameter in this suUcnient. styleManaQer_icofi refers to a 
Iwation in the fnnit [janel window. The exact rjefmitirm of 
the local ton — die window's x,y location with i-especi lo tlie 
FrortPanel window^ — is nol present in the program Imt is de- 
clared iu a flle called the fihjrrf ntap. At execution time the 



Table 1 
Synlib Capabilities 

Ftmctions to Name GUI Objects af Interest 

Syn Name Window 
Syfi N ame Wi n dcfw ByTitlfl 
Syn Name Location 
Syn Name Reg ion 



Functions to Deliver Inputs to Named Objects 

SynCliCkButton 

SynClickKey 

Syr P re ssAnd H Q Id Button 

SynReieaseButtpn 

SynMovePointer 

SynPnntString 

SynPressAndHotctKey 

SynReleasBKey 

SynSetFDcus 

SynSeieciltem 

Functions to Synchronize Application State with 
Test Agent 

SynWartWrndowMap 
SynWa itWf ndo wU nmap 
SynWartWi ndo wConfigurB 
SyrtWaitProperty 



Functions to Verify the State of a GUI Application 

SyrGetShellArdTitle 

SynStorelEKt 

SynCompa reWindowl mage 



JVliscellant^ous Fiincl:ion>>i to Process Needed 
Test Resources rroni the Environment 

S yn Pa rs e C m m a n d pt 1 n s 
SynParseObjecMFfle 
SynBLJIdFocusMap 
Syn Parse Key Map 



objcHf uuip is made available to Ihe S>Tilib aj^enl Ihruugb a 
comrnmid line (jption. The agent consults liic (tbj**ct map lo 
decode the exact location of Oie named object styleManagtc 
icon, then drives the mouse to the decoded location and 
presses the button. Because the location is soft coiled, the 
progi'itm itself remains unclumgcti even if Ihc* front [y*nn^l 
configuration changes or if the exact location of I be named 
object is different on a different tlisplay The named location, 
styletVIanaQer_icDn, represents a sernanlif* culily whose nteaning 
is indcjumdcnt of the platfonu or the display or the revision 
of the target apphcation. The semantics of the name is 
mem^ingful r>nly in the tf^sl. In other words, the test remains 
t>oi1able. If fbaugcs in tlu^ platfomi. display, or application 
require \\ui\ the exact Itjcation of tlie najiuni object be 
ch;mge(i, this is actiievcd either by I'tliling tiie oliject map 
file or by supplying a different objetrt map Ole specific ftjr 
the platform. Synlib pro\ides automated methods to viWt nr 
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generate environment -specific object niap files. The a^ent 

itself tlcK^H ii(3l need any change. 

The fomiar of a typical SynOb objc^ct map is: 

I Object Map for the sample program 

I Declares the locations named in the test 

1 program 

Location stYleManager_iGOn 7 81 51 

i Declares the full path of an item named in a 
\ focus map 

FocusPath S tyl eManager_ I con_ Focus Path 
Front Panel * Act ionl cons .dt style icon 

Focus Maps 

A far superitjr metliod of naming GIJT objec^ts nf intprest Ls 
to use Sy 111 J tils concepts o[Joras tttaps midjhrus paths. A 
focus map is a clescriplioii of the logical oi giuiizal ion of tlie 
input enabled objecis in a widget-based application. j\n 
mput enabled objet't is a region in a window that can accept 
keystrokes or button inputs fron) a usen (jenerally these 
objects are widgets or gadgets uyed iii consi meting the user 
mterface. 

The method of constructing a focus map is fully described in 
the Syitlib User's Guide. ^ A more complete description of the 
concept of a focuy map and its use in testing X wuidows 
applications has been published elsew^hcrp.- A focus jiatb is 
a string of dot-separated natnes declared in a focus map. For 
example, StvfeManager_lcon_FociJsPath is the name of tlie fociis 
path FraniPaneE.Actionkonsdtstylelcor, which is a string of dot- 
separated names tieclared in tlie focus ruap named FrontPanel. 
Focus ma]7s are descrilied in focus map Hk^s. Focus paths, 
on the other hami, are decimx^d ii^ object uiap files because, 
when associateci with a window, a focus path identfies an 
actual object capable of accepting input. 

In the example program above, the function SynSelectHem^l 
represents an ii^stmcliou to the agent to select the object 
named by the striiig Style Manager, I con _FocusPath, which can be 
tieclared m tlie ol>ject ma|j file as siiown above. 

The following is the focus map for ttte front panel window. 
I 

1 Focus map for the default front panel window 
I of the CDE desktop. 

^FocusMap FrontPanel 
(FocusGroup ActionXGons 

(App, Panel dtpadlcon dtmaillcon dtlocklcon 
dtbeeplcon workspace One wo rkflpace_ Three 
workspace_Two workspaGe_Four exit Icon 
printer_Panel printerlcon dtstyleicon 
toolboxicon Help_Panel helplcon trashlcon 
dtcmicou dtf ilelcon) ) ) 

I 

If Hie proper focus maiJ mul object maps are provided, the 
agent will apply S^nlil) embedded niles to decide how^ to set 
focus on the named item and then select or activate the item. 
During execution, Synhb fii^st processes all supplied focus 
maps and creates tm internal representation. Whenever the 
program refers lo a focus patli, S.vnilib decodej^ tlie itlentity 
of t lie desired object Ijy tmalj^mg the focus map in w^Mch 
ttie focus path occLm>, Using tlie declarations in the focus 
map tUid a[}plying OSF/Motif supportf^d kt^yboai-d txavei^al 



specifications, Synlib generates a series of keystrokes to set 
the keyboaiTJ focus to the object indirectly rtam^^d \ia the 
focus |>ath. The rules for transforming the foe as path name 
to the sequence of keystrokes are somewhat complex and 
have been fully describe^d elsewhere,^ These rules are ent- 
bedded uy Sjiilib and are completely transpaJ^ent to the user* 

This example shows the use of a focus map in naming icons 
\n the fronl panef AliluKigh ifie exauiplehere deals with a 
simpie situatioUj die same principles and methods ctu\ with 
equal ease be used to Jiajiie and access objects in deeply 
embedded structures like menus atid subnu^nus. In general, 
naming objects l>y nieans of a foe its map is fai^ suj jerior to 
naming them Ijv means of an object map. Becausf^ access 
to the objects of interest is via a dynamically generated se- 
quence of keystrokes, tlie programs employing tliese nietlwds 
are resistant to changes hi windoW' size, fonts, or actual 
ol)ject kications. Tliis makes the tests com]jletely portable 
across platfonns. disj>lays. and otlier envdromnental variabi- 
lities. SynJib j^rogranis using focus maps to name CtLT 
ol)jects need not be chmiged at ail unless the specification 
of the target applicafion changes. 

l^suig a sitnilar soft cocking teclinique, Synlib makes il pos- 
sible to create lorttl/^ ticuiml tesls. thai is, tests that can 
verify the behavior of targei applications executing in differ- 
ent language environments without undergoing any ciiange 
themselves. I'se of this technique luis substantially reduced 
the cost of testing inieriiailonali;ced <jlJl ai>plication.s. A 
complete description of the concept of locale neutral testis 
has been pubhsbed.'^ 

Test Exeeution Architecture 

Syulilj pifnitles concepts and tools that enable us to create 
"one test for one apt^licalion." The tests, assisted by the re- 
quired envu'Oiuneut dependent resomx'e fUes Uko object 
urap, focus maiJ, and key map files, can verify the l>ebtivior 
of taiget ajjphcaiiiuis executing tm differeni phutnniLs, using 
different tlisplays, anfl working tn very different language 
environments. 

Fig. 2 shows an execntion itrchitecttue for Sytvlib tests. A key 
map file contains declarations to nanie keystrokes, button 
events, and se{|uences of keystrokes and button events. Tin* 
key mail file provides a way to viitualize ami name all ininits 
to be used by a test program. Tliis mechanism is vex}' useful 
for ureating tests for internationalized aiiplications and is 
fully described in reference 4. 

The cost of creating or modifyitig Ibe environment resource 
files LS minuscule compared to the cost of creating the tesls 
themselves. Thus, the abihry to create tests that sie insensi- 
tive to dilTcrences m the execution environment of the tiuget 
apphcaiion has been a great productivity^ boost to our testing 
efforts, 

A feature of Synhb test technology is that it does not require 
any change in the target a]3phcation. It does not require that 
the apphcaiion code be modified in any way. There is no 
need to i:ncori)oiate any test hook in the api>licaliun, nor is 
the ajiplication required f o relink to any foreign test-speciTic 
libr^u^; S>iihb sui>poils a com])letely noninvasive testing 
framework. The test is directly executed on the appht ation 
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FI^. 2* Synlib test exefriirion architecture. 



off the sliel£ Synlib even makes it possible to write the tests 
before the applicatiOTi is ready for testing.^ 

The author originally designed Synlib to solve the problems 
of GLU testing facing oiu" lab, mainly testing (jV] applications 
that supported a variety of HP displays and operating sys- 
tems. We designed Synlib to provide a technology that yields 
robust iind platronii-lnsensitive tests at a low cost. S>iilib 
proved to be a man-eloiis Hi for testing the CDE desktop 
since one of tlie main cotuiitioris was that the teats would 
have to verify applications nuuiing on the platforms of the 
four participating coinpmiies. Essentially il was ^ prf jbleni 
df creating platfonn-insensitive tests, a problt^n that wc had 
already solved. Tlie success of S>Tilib in this entleavour is 
shown by the large body of fiuictioniag test suites Un tlie 
complex applications of the C*DE desktop. 
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A Hybrid Power Module for a Mobile 
Communications Telephone 



This article describes a 3.5-watt power module designed for a GSM 
[Global System for Mobile Communications) handheld telephone. The 
design features proprietary silicon power bipolar devices, lifmped 
elements for input interstage, and output matching, thick^ilm alumina 
ceramic technology, and laser trimmed bias resistors. High-volume 
manufacturing was a design requirement. 

by Melame M< Daniels 



Power mudules, as discussed in ihis ankle, are the output 
stage of the RF (radio frequency) amplification ctiain in a 
mobile telephone (Fig. 1). Some telephones use integrated 
circuits as power soiutionSj but tor output power greater 
than one watt a discrete device is usually used. A power 
module uses networks To match the discrete stages m a 
hybrid aniplifier, 

TliLs article describes a power module designed for a GSM 
(GlobaJ System for Mobile Corurnunicalions) handheld tele- 
phone. GSM telephones transnut in the frequency range of 
880 to 915 MHz, The peak transmitter cairier power for 
power class 4 is 3.5 watts at 1/8 duty cyc^e. Lin like other 
TDMA (time thvision multiple access) systems, it is possible 
to nui a (tSM i>ower module close to compression because 
the mnplitude is constant using GMSK (Gaussian miniinmn 
phase shift keying) modulation. Tlie pulse width of tlie 
transmission burst is 577 microseconds, mid the rise time of 
the powder module must be loss than 2 |is. It is necessarj' to 
supply fidl output power at a supply voltage of 5.4 volts (five 
NiCad cells at end of life) with 40^Jb efllciency aiul 0-dBm 



input power. This Ls a requirement of the customer for the 
]')hone to be competitive. Future generations of phones may 
use only four NiCad cells or otlier batteiy t>pes and volt- 
ages. Of course, a handheld phone must be inexi^ensive and 
small and have long talk time (i.e., efficiency) and this dic- 
tates tlie speciScations for the power module. 

The desigTi goals called for the power module to be smaH, 
inexpensi%'e; user friendly, efficient , and maiiufacturable in 
volume, and to supply full outj:)ut power. 

Silicon bipolar devices were chosen over GaAs PET devices 
for this product because of their cost advantages and the 
fact that IIP had developed tiew silicon power devices that 
met the stringent requirements of applications in which 
GaAs had trachtioually been used (i.e., low de\ice vottages 
and excellent efficiency). 

Fig, 2 is a photograph of the power ntodule. Tlie schematic 
diagram, Rg. 3, show^s the electrical design of 1 he power 
module. The bias circuits must be simple and fast because 
of the pulsed nature of the GSM modulation. Because of the 
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Fig. 1. IJtcJCk diagram of a tjpical handheld digital telephone. 
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Fig. 2. ilSM power module evolutioB. 

low voltage requirements, proprietary silicon power bipolar 
de^ites were de%'elopett The eol lector of each stage simply 
has an RF choke to the 5.4V mininmm supply voltage, V^^^^, 
and a bj^pass capacitor to ground. The base voltage supply is 
used lo turn the amplifier on and off and to control the out- 
put power level of tlie [uociule. The control voltage, \,., is 
pulsed at 1/8 duty cycle with a square wave from (iV when 
the module is off to 4.0V when tlie module suppUes full out- 
put power. The base of each st^ge has a series resistor to 
the control voltage. This resistor is adjusted to compensate 
for each transistor's cm"rent gain, fi. This is done using ac- 
tive laser trimming and wiU be discussed as a separalje topic. 
Since the power control voltage suppliefl l>y the phone does 
not ha\'e the capabilily of supplying the liasc cuiTent of each 
stage, a low-lretiuency n-p-n transistor, Q4. is usvti lo buffer 
the control voltage. Ttie collecl<:jr of Q4 is biased by iJte sup- 
ply voltage, Vcc. The base of Q4 is driven by the power con- 
trol voltage and the emitter supplies the necessary voltage 
and current U» the l^ase of each f{F stage. 

The RF design uses lumped elements for input, interstage, 
and output inatchhig. The design requires tlu'ee stages tfj 



achieve the gain requirements. TTie first .stage is a driver 
stage that is class-A biased. The second and third stages are 
class- AB biased for efficiency; 

The third-stage transistor also has some internal matching 

witliin the package. Tlie input impedance of the sOicon power 
transistor chip is about L5 ohms. Tins must be tiansformed 
up to a larger impedance by a matching netft ork that is 
phj-sically as close to the chip as possible. This Is achieved 
using a ft (KM -inch-diameter bond wire as a series inductor 
from the base of llie chip to a shunt MOS capacitor at the 
input of the transistor package (Fig. 4). This configuration 
niakes a very- higli-Q input matchii^g network. The exact 
value of capacitor and the length of bond wire had to be 
empirically optimized lo achieve the maximum transforma- 
tion within the transistor package, 

Tlie most critical and seiisltive part of the matching netw^orks 
is the output of the final stage. Iligh-Q lumped-t*lemen! com- 
ponents are used in the output matching net w ork to acliieve 
the low losses necessary to meet tlie efficiency requirements. 

Since the design has more than 45 dB of small-signal gabi in 
a I -inch-by-0, 5-inch package, stability and isolation were quite 
challenging. The i>lac*ement and \alues of tlie RF chokes ai\d 
decoupling capacitors were critical. Large-vaUie capacitors 
could not be placed on the base bias network, sitvce this 
would slow down the pulse response of the ntodule, 

MechanicaJ Design 

As previotisly merit i one d, some of the primtu^^ design goals 
were (I) low cost because tliis is a comniercial jjroduct, (2) 
small size tt> allow phone maniifarturei's to (iesign smaller 
products for porl:abiht>^ (also a competitive advantage for 
HP), and (3) compatibility witli high-vohinte matiufactiiring. 
In addition, the power module component had t< j be supphed 
as a surface mount component ir^ lai^e-mMl-reel lonn. Tlie 
mechiuiir^Ll design of the power riKKiule tuniefi out to be one 
of the most challenging parts of the deveUjpm€*nt project. At 
the tune the project was stiuled, most coint>etitors were 
using sofi b(jard for the substniU^ nmterial and siutace mount 
luniped components for mat4;hitig. This material definitely 
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meets the cost eriteria, but there were thermal, EF matelimg, 
aiid laser trin lining ILniitations. niick-film iilumina ceramic 
technology was chosen for the boajd material. Even though 
the material is more expensive. Uiis is offset by the fact that 
the RF matching networks are more compact because of tlie 
high dielectric const*mt e^ ^9,1. Also, the resistors and m- 
ductoi-s call l>e printed on the board, ilius reducing the part 
count. Ceramic has su[>erior tliermal con duct! vity compared 
to soft boards. The most persuasive reason for ceramic sub- 
strates is that they do not require a metal carrier to be sur- 
face moiuitecl Tlie \ias in a ceramic lioaicl can be filled \vitli 
metal paste so components ctm be placed directly on top of 
the via This reduces the eniitter-to-ground mductance for 
the ti"ansistors aiid gives superior gain and efficiency perfor- 
mance. This factor also reduces the size of tfie module to 
1 inch by 0.4 inch. Standard surface mount cf>jri[H:>ntMUs on 
PdAg traces aie used for lumped-element matcJiiiig and cus- 
tom surface mount packages are used for the RF transistors. 

Tlie uiputs and outiauts of the poM^er module use wiaparomid 
edge vlas. Tliis is commonly refen'ed to as an LCC Headless 
cliip carrier) for surface mount component manufacturers. 
It is inexpensive because ik.j leailframes need to be attached. 
The metal thick nirn used in tlie vitis must pass all solder- 
ablHty tests. 

Volume Assembly 

Fig. 5 sho%vs tlie process flow for manLifactuiing the power 
moclules. Mod ides are built in array form v^dth 40 modules 
per 4-inch4>y4-inch array. More mo<lules per array reduces 
the ceramic substrate cost mid the surface momit assembly 
cost but also increases the complexity of substrate manufac- 
turing. The boards are populated by a subcontractor with 
standard [ack-and-place equipment, then reflowed at a peak 
temperature of 220 'C using SN96 solder paste. Tlie high- 
temperature reflow- was chosen to prevent a secondaiy re- 
flow by the customer when the power module is surface 
niounted into tlie telephone. De\^oloping the reflow^ profiles 
%\1lh the chosen fliick-fihn paste and high-temperature solder 
was not a trivial task. 

The populated arrays are then actively laser trimmed. Each 
base bias resistor (three per module) must be trimmed witli 
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Fig. 5. Volume assembly process flow. 
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the laser to set the transistor collector current. This is to 
compensate for p \^riation in device fabrication^ The sinipte 
bias scheme was chosen because we couldn't afford the cost 
and efficiency loss of an active bias cLrcuit, Developing the 
laser trim process was ariDther challenging aspect of this 
producL 

Two of the transistors are biased off (have the bases 
grounded) while the tliird is being irimnied. This is nec^- 
sar>* 10 avoid oscillations caused hy the high gain and the 
dtCBcuJty of adequate grounding while the modules are in 
array form. Extensi^'C de%'elopment was required to obtain 
good RF grounding on the backside of the module and in the 
bias probes while laser triiimiirig. A grounding gasket made 
of silver impregnated rubl^er is useil ^dih a vacuum to 
achie%T backside grounding. High-frequency probes with 
good 50-<5tmi loads are used on aU inputs and outputs to 
avoid oscillations. 

Special software was developed for the laser trimmer. Algo- 
rithnis were \vrilteTi to compensate for tlie current drawn 
througli the grounded-base transistors. In addition, the resis- 
tors cUhI transistors heat up during the trim process and this 
has to be conipensated, Tlie trim process h^is lo be done In a 
puLsed bias mode, since the module cannot be iiin in CW 
mode witiiout thermal nmaway. Finally, the outpiit power 
cannot reach saturation before tlie maximum control voltage 
is reached, since this impacts the customer's power contiol 
loop. To resolve this issue, the UKKliiles are trimmed at a 
control voltage of 3.2V maxin^uni. 

After laser trimming the Dds are attached in aiTay form. Tlie 
array is then separated into indi%idtml units, which arp 
tested using automated test equipment. All of the problems 
addi-essed for the laser trinmiing were also present for the 
automated test process. The mcjdule groundiiig is absolutely 
critical to testing RF parameters. Developuig test fixtures 
that could test hundreds of modules per hour, three shifts a 
day, and still retaiti a good RF groiuid was critical lo tlie 
success of the [iroducl. The average test time per moduJe is 
20 seconds. The automated test programs mv complex be- 
cause of the n timber of tests that have to be perfomied and 
the fact that they all have to be done in pulsed mode, 

IVansistor Modeling 

Trmisistor tiiodeling was used to develop lincEU' ajid noniuiear 
device models lor a single cell of the transistor used in the 
power module. These building blocks were then used to 
model tlie ent ire power module. The modeling efftirt included 
con'elating ineasmed device data Willi the models anr! mo(Ji- 
fying the models when necessiiry. The HI' Microwave Design 
Sj^tem wiis tised for the linear ajid iu>nline;u^ modeling of 
the device and the package. 

The first step was to use parameter extraction techniques U) 
get a Gunimei-Foon SPICE mtKlel ^ of the single-cell device. 
Next, models were ileveloped for' tlie packages. 

To make low-voltage bipolai' transistors, many new prtK-eases 
were used. These devices have fine geometry to achieve the 
higher gain necessary for talk-time efficiency. This chajiged 
many of the model parameters traditionally used for silicon 
power transistors. 




Fig, 6, Single device cell. 

The single device chosen for modeling actually consists of 
four separate quarter cells on each de\iee as shown in Pig, 6. 
Each quarter cell has 40 emitter fingers with each finger 
having an approximate capacity of 2 mA of continuoiLs cur- 
rent. With the existing technology it was not possible to ex- 
tract the parameters of the entire device with 160 fingers 
and a maximum cun-ent of 360 mA, so the quarter cell with 
40 fingers was used for the parameier extraction. These 
devices have HP proprietary' epkaxial material and geome- 
tries. 

The device was placed into the standard 86 package shown 
in Fig. 7 for tlie second stage of live power module. This is a 
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Fig. 7, Stfirirlard S6 package. 
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plastic encapsulated package used for high-voiume manu- 
facturing and iow power dissipation. The output stage has a 
custom package as shown in Fig. 4. Thermal dissipation is 
not a mBUor issue in our application because of the 12.5% 
duty cycle pulsed opemtion. 

Tlie Ebers-MoO model^'^ is a good general-piiipose model, 
but is not sufficient over wide regions of tiiieration because 
of approximations in the equations. The Gmnniel-Poon 
model ^ takes second-order effects into accoimt and gives 
more accurate results. The model we used is a modified 
Gummel-Poon model. ^ The n-p-n transistor dc and ac cii- 
cuits are shown in Pigs. 8 and U respt^clively. 

Among the second-order eiferts included in the Gunmiei- 
Poon model is jmiction caj^acitance in the emitter^ base, and 
collector. Tlie Ebers-MoH model holds these capacitances 
constant but they are more accurately modeled in the 
Giunmel-Poon model as functions of junction voltage. A 
loial of nine model parameters are needed to model the 
junction capacitance accurately^^ 

Finite resistiince arKi the clfccls of surfaces, high ciuxent 
injection, and nomdeal diodes make Ihe collector and base 
current vary nonuniformly with base-to-emitter voltage. 
These effects are modeled using two diodes. 

Another complex second-order effect is the variation of unity- 
gain l>and widths iVr with 1^. and V^^. At low^ ciurents. f^^ is 
almost (oUilly dependent on the g^^ of the dc\iee and the 
junction capacitaiice/' At juoderate currents, the diffusion 
capacitance at the base-emfttjer and base-t^ollector junctions 
staits to cancel ajiy increase in gm, which causes fj to remain 
constant. Tliis is the constant transit lime region, Al high 
currents, the forward nansit time of Ihe tnuisislor increases 
because of space charge limited current flow, which leads to 
base widening and tw^o-dimensional iiijeetion effects. 

All of the parameters of the modified Gummel-Poon model 
ai'e extracted vising a modeling system developed by IIH 
Complete and accmate model parameter sets can l>e ol>tained 
in about two hours using Hewlett-Packard's test system ^ 
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test and modeling software, and new modeling methods.*^ 
A through-reflcct-hne (TRL) ctdibration method is used and 
the fixture tmd bond Wildes to die de\ice are comijletely 
characterized and deembcdded to get an accurate model of 
the device alone. 

At the time this work was completed, it was not possible to 
measure large transistors because of the limitations of the 
dc power supplies and thennaJ dissipation problems. To over- 
come this difficidty, one quarter of the cell was extracted. 
This was possible since there wtts a small qu^uter-ceO test 
transistor on the original etigineermg wtd'er as shown in 
Fig. 10, The Gummcl-Poon SPICE file that was obtained by 
HP's parameter extraction software of this quarter cell is 
shown in Fig. 1 J . The schematic for the SPfCE file can be 
seen in Fig. 12. 

Since this work was compJeted, HP has developed a piUsed 
parameter extraction system that can measure power tran- 
sistors aj\d a power GiunmehPoun rtiodel is being developed 
to compensate for ihermaJ considerations. With the basic 
n^odel obtained! previously, however^ the model for die entire 
de\ice was fieveloperi on the HP Microwave Design System 
by paralleling fom' of the quaiter cells as shown m Fig. 13, 
The quarter cell has one base and one emitter pad as shov^m 
previously in Fig. 10. The entire ceU has one base pad for all 




Fig. IQ. Qiiarler device cell. 
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SUBCICTnifitsmelll 

LE3 4 3EI0 
LfiZ56E'10 
CRKBE2 31E-M 
CRXBC213E-14 
CRXECT3 2I4J 
CPADBC5141E-13 
CPADEC4 14.1E-11 
m 1 5 4 NPN 
*AflEA = 1 
MODEL NPNHPN 

+ BF^ 280.7 

+ t«F = 0J935 

#VAF = 33.16 

+ mf = 299,9 

+ IS£ = S.91E11 

+ I4E^2J99 

+ BR = 54.61 

+ NH = D 98B8 

+ VAR^T-511 

4lKR = el 

4lSC-8i74£-t3 

+ m ^ 15B7 

+ RB = 0,752 

+ IRB = g 

+ mfA = 

i-RE = 2.44« 

+ RC = 1-22B ~ -- - - ^ 

+ )rrfl=o 

+ EG = 1,11 
+ XT3-3 

+ CJE = 5.055E 12 
+ VJE = 1.148 
+ MJE = 05965 
+ TF = 1.6E-1! 
+ XTF=^0.0(M5G 
+ VTF = 0,02785 
+ rTF = O.QDI 
+ PTF = Z3 
fCJC = 1J52E T2 
+ VJC = D.4776 
4MJC = O.Z5O0 
4XCJC-0 001 
+ TR = 1£09 
+ R: = 0.999 
ENDS 

Fig. 11. tjuartier-cf^ll HFICK paraniPter extraction Gutput. 

four re Us and onp emitter pad for two cells as shown in 
Fl^. 6. This m\is{ \.w comppn sated in the models. The param- 
eter extraction SPICE file (Pigs. 1 1 and 12) elearly shows 
die r 11 pari lance of both the base and emittei^ pads, CPAD8C 
and CPADEC, respec'tively. The two-eniitter-pad capacil^inee 
and the one-base-pad capacitance are added to the model of 
the four parallel quarter cells f Fig. 13) as components CMPt03 
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Fig. 12. Uuaner device eetl schenuirit of Hm^ SPICE file. 
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Fig. IS. HP Microwave Deagn System mode] for a full siiigle ceil. 

and CMP106. This file is the basis for the models of the fiill 
device. 

Separately, similar parameter extraction methods were 
performed to model iJie 86 package and die custom output 
stage package. The 86 package lias been modeled exten- 
sively for use with other products and can be found in the 
HP Components E>ata Book.' The HP Microwave Design 
System package model for the 86 package is shown in 
Pig. 14. 

Both of these models were used for linear and nonlinear 
designs of the power module. Agreement between the mea* 
sured perfonnaru^e and the simulated (performance was 
excellent fr>r the linear design (within ±0.5 <iB of gain] and 
good for t be n(.>nlinear tiesign (\^"itllin ±2 dBm of the 1-tlB 
compression point ), The perft^nnance of tlie models was 
gtjod Ijeraiise this was a pulsed apphcation and deviations 
been use of thermal considemtions were m>t a factor. 

Re^ulti^ 

Thi^ (iSM power module was engineering released in 
Nov'ember i99'S and manufacturing released In May HJ94. 
(Jver one million of the original GSM power module have 
been shipped and the module ha** since gone through two 
design upgrades to sniiilk^r ajul it^adless modules to satisfy 
customer redesign nee(is. We now ha\'e a nuumfacturiug line 
and processes tliat aie behig used for new products. Tlic 
module has bef*n a success ui tlie power cf*llular market.. 

Project Management and Acknowledgements 

This was mui is a glul>til project /fhe customers and sales 
offices are in Europe and the wafer fab is in Newark, Call- 
fomia. The nuirkc^iing team was originally in San Jose, Call- 
foniia, the R«^l) team was in Folsom, Califoniia, and the 
manufacturing teani was in Malaysia and Folsom. Wc^ harl 
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never worked together before and there were laige learning 
curves, HP's Malaysia operation had never manufactiired a 
product using thick-film suilacc mount technologies T^lth 
the complex EF testing and active laser trimming required. 
The enghieering team had never designed a product for 
these high volumes. Conunumcation and project maiiage- 
nient v^ere criticaL Many hours were spent on the phone, in 
meetings, wri ling email and traveling. I would like toac- 
knowletlge Hanaji Zurkowskij Tliomas Franke, Hich Lcvitsky, 
Mark Dunn, the power module groups in Folsont and M^iJay- 
sia, and Ihe field sales team for their contribiilions tt.> the 
success of this project. 
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Automated C-Terminal Protein 
Sequence Analysis Using the 
HP G1009A C-Terminal Protein 
Sequencing System 

The HP G1009A is an automated system for the carboxy-terminal amino 
acid sequence analysis of protein samples. It detects and sequences 
through any of the twenty common amino acids. This paper describes a 
number of applications that demonstrate its capabilities. 

by Chad G. Miller and Jerome M. Bailey 



Peptide and protein molecules are composed of amino acid 
molecules covalently coupled end-to-ei^d tJncjugh peptide 
bonds, resulting in linear sequences of the amino acitJ resi- 
dues* These pol>i>eptide molecules have iwo chemically 
distinguishable i.ennini or ends, idenlifRMrl as rhe ainir\o (N) 
terminus and the carboxy (CJ tenninus. 'Hie N-teniiinal and 
C-teniiinal annuo acid residues define the ends of the amino 
acid sequence of the polypeptide as depicted in Fig. 1. 

The amino acid sequence of the polyi^epttde molecule im- 
parts its chemical prof>erties, such as the ;31) spatial eon- 
fonnation, its biological properties including euzymatic 
function, its biotnolecular recognition (in^niuuologic) prop- 
erties, aiul its role in celhiiarsluijjc and architeclure. It is the 
acttjaJ amino acid setjuem^e of the polyi>epti(ic i\\w tjrder iu 
which the amino acid residues occur in the ludypeptide 
from temiiinis to tennitnis) rattier than the aininr* acid com- 
position as a rantlom linciu* arraugement that is (^nicial In 
defiding flu^ stnicturai and ftinctional attributes of peptides 
and pi'otcius. 

C-tcnninal amino acid sequence analysis of peptide and pro 
teln samples pnmdes cnjcial stiijctural uiionnation ftjr 
bioscientistiu. Deterniinatioti of the amino ac^id sequence 
constituting the C-tenrniui of proteins Ls required to define or 
verify f validate) the full-length stnictural integrity of native 
proteins isolated froni natnral souixes or recomijiiiantly 
expresse<i protein products that are genetically engineered. 



N-Tenninus 



C-tBrmmiiS 



no RD RO RO 

'^NHj Cn+i C NH Cn C NH C; C NH Ci C OH 
H K n H H 

Fig. I. Aiilukj acid Hequence of a polypeptide depitliiig I in? 
N-terniinal t'nd (intlicated by the snbsnrijit n + l) arid the f- 
tpniiiiml end (iudirated by the stibscripl I) nf the niole<;ule. 
with the intervening amino acid residues indicated by the sub- 
script n. C-itTiniiial st*quenf'e analysis begins at the (^terminal 
amino ^nd re5?i<lu(^ mid soqtif^ntiMlly df*gnicifs tiie pi)lyp(*jjtidi* 
toward the N-terrninal amino add residue. 



The cellular processing of proteins at the C-tenninus is a 
relati^'ely cojnnion event yielding proteias with varying de- 
grees (jf ;nniiKJ 'Avn\ truncatiou.s. (teletirjiis, and substitutions.^ 
The processing of tlie C-terniinal end of the protein results 
in a family of fragmented protein species temiinating with 
different amino acid residues. The N-terminal amino acid 
sequence, however, may remain identical for all of these 
protein species. These ragged C-tennifiui i>ro!eitts often 
constitute the fauiily of matiue protein forms flerived from a 
single gene expression. Many proteins ;md pept ides aje ini- 
tially bios:^iithesized as inactive large precnrsors tJtat ai'e 
enzymatically cteavetl arui processed to generate the mature, 
smellier, tjioactive fomis- This t>pe of post -fmnstatio nal 
processing also serves \o mediate the cellnlaj^ levels of the 
biologically act i\^e forms of peptitles and proteiiLs. Informa- 
tion derived solely from t)NA ;malysis does not pemiit tlie 
preitiction of th(\se jkisI frauslaiionnl tiroteolytic f processing 
events- The idetni Heat ion ijf the resuhtUii C-ternnnal amino 
acids helps elucidate these cellular biosynUxetic processes 
and control me<'h£misms. 

The polypeptide alpha-amino antl alpha-c^tutjoxyUc acid or- 
ganic chemical fnivrtional grfnuJ-'^f^i^th*' N-tenniiiaJ and C- 
ternnniil amino acid residues, resijec lively, ;ire snmcictitly 
different to reiiuu'e different chemit^^il methods for the de- 
termination of the amino acid sequences at these respective 
ends of the mr>lecule. N-tenninal protein sequence analysis 
Inis been relnied o\er the couj"se of four decades and is cnr- 
rently tin exci^plioually efficient automated chemical imalysis 
melhotf The chenncal (inicletjphilic) reacti\ity of the alpha- 
aitiino grout» of the N-tenninal amino acid residue permits a 
facile chemical sequencing process invoking a cyclical degra* 
dative s<*heme, fna dam en tally baseri on the reaction scheme 
fii^t introduced by P. FJdman in 195(j,^ Automation of the 
N-tennin?d sequencing chemistry in HlfiT resnlte<^l in a singe 
of protein amino a<:id sequence infrmnation avjulable for 
bioscieutists/^ 

The nuKii h\ss ciiemicalty reactive alpha-carboxylic acid 
group of die C'-terminai ajniuo acid residue proved to be 
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Abbreviations for the Common 
Amino Acids 





Three-Letter 


Single-Utter 


Amino Acid 


Code 


Code 


Alanme 


AJa 


A 


Asparagine 


Asn 


U 


Aspartic Acid 


Asp 


D 


Arginme 


Arg 


R 


Cystefne 


Cys 


C 


Glycine 


Gly 


i 


Glutamine 


GJn 


Q 


Glutamic Acid 


G!u 


£ 


Histidine 


His 


H 


JsoJeucine 


He 


1 


Leucine 


Leu: 


L 


Lysine 


Lys 


IC 


Methionine 


Met 


M 


Phenylaisnine 


Phe 


f 


Proline 


PfQ 


P 


Serine 


Ser 


S 


Threonine 


Thr 


f 


lyrosine 


Tyr 


Y 


Tryptophan 


Trp 


W 


Valine 


Val 


V 



exceedingly more challenging for the development < jf an 
efficient chemic al ^sequencing process. A vaiiety of C-tenTiinal 
chemical sequencing approaches were explored during the 
period in which N-terminal protein sequencing usmg the 
Fjdman approach was optiini/.etT^'^ None of tht* G-terininal 
chemical reaction schemes described in the literature 
proved practical for amuio acid sequence analysis across a 
usefid range of molecular w^eight ancl structiu'al complexity, 
Carbt)xypeplidaae enzjTiics were employed to cleave the 
C-tertniiial amino acid residues enzymatically from intact 
proteins or proteolytic peptides. These carboxypeptklase 
digests were subjected to chromatographic analysis for tlie 
identification of the protein C"-tenninaJ amino acid residues, 
Tliis manual process suffered from the inlierent enzyuTatic 
selectivity of the carbox^peptidases toward the amino acid 
residue type and exliibited protein sample-to-sample vaii- 
abtyty and reaction dependencies, The results frequently 
yielded ambiguous sequence datii. The tyjjical results were 
hi conclusive and pro\idefT more often Lhaii not, amino acid 
con^positi final uifomiation rather th<iii unambiguous se- 
quence information. An alternative a}i[>roach required the 
proteoiytu^ fligestion of a protem sample (t\pically wilh the 
enzjine tiypsin), [>reviou.sly chemically labelerl (modified) at 
the protem C!-tenninal amino aciil residue, and rJie chromato- 
graphic frEictiojiation of the result ing peptides to isolate the 
label etl C-teiTnuial peptide. The isolated t>^ptide was sub- 
jected to N-terminal sequence analysis in an attempt to iden- 
tify the C-terminai ammo acici of die peptide. Tive hmited 
amount tmd quahty of C-temihial amino acid sequence infor- 
mation derived from these considerably tedious, multistep 
manual methods appealed to apjily best to suitable model 
test peptides aiid proteuis aitd offereti iittle geneiality. 



HP Thiohydantoin C-Tenuinal Sequencing Chemistry 

The general applicability of a chemical sequencing scheme 
for the analysis of the protein O terminus has only very re- 
cently been reported and developed into an automated ana- 
lytical process.*^ The Hewlett-Packard GlOflOA C-terminal 
ju'oteni sequencing system, irUroduced in July 1994, auto- 
mates a C-termitial chemical sequencing process developed 
by scicntLsts at the Beckman Research Institute of the C-ity 
of Hope Medical Center in f)uai1e, California. Tlie overall 
cliemical reaction sctieme is depicted in Fig. 2 and consists 
of two principal reaction events. The alpha-carboxylic acid 
group of the C-tenuina! amino acid residue of the protein is 
modifiefl to a chemical species that differentiates it from 
any other f onstiluent amino acid residue in the protein 
sample. Tfie cltemical modification involves tlie chemical 
(muplh}Q of Ihe C-terminai anuno acid residue with the se- 
quencing coupling reagent. The modified C-tei-minal amino 
acid resichie is in a chemical form that permits its facile 
chemical cleavage from the rest of the protein molecule. The 
clea%'age t eaction generates die uniquely modiHed C-temiuia] 
amino acid residiu* its a diiohydmUom-amino acid (TH-aa) 
derivativej which is detected and identified using HPLC 
(iiigh -performance Uquid chromatography) analysis. Tiie 
remaining component r>t't[ie cleavage reaction is the protein 
short cue d by one amino acid residue (the C '-terminal amino 
acid) and is sni^iected to the next round of this coupling/ 
cleavage cycle. The overall sequencing process is tiius a 
scquentiaJ chemical degradation of the protein yiehliiig 
successive amino acid residues from the protein C-tenniiuis 
that are detected and identified by HPLC analysis. 

As shown in Fig. 3, the coupling reaction event of the se- 
quencing cycle begins with the activation of the carbox>^hc 
acid function of the C4erminaJ ajuino acid residue, promoting 
its reaction witii the couphiig reagent, diptienyl pliosphoryl- 
isotlnocyaiiate ( DPPITC). The reaction is accelerated in the 
presence of pyridine and suggests the forniation of a peptide 
pf)osphoiyl anhydiidc species as a plausible chemical reac- 
tion intennediate. The final product of the coupling reaction 
Ls the j>cptide lhit)hytlantoin, Foniied by chemical cychzafion 
of the intermediate peptide isotliiocyanate. 



NHj 



NH^ 



NH? 



CO^H 



Chemical 
Caupling 




Chemical 
Cleavage 




CO^H 




Fig. 2, Uvenill reaetlojt scliente of the C-X^nnlnnl sequencing 
|irac( ss depicting liie initial thetnical coupling reaction, modifyiag 
the C-lemunal imiiiio add (as indiratei:! by a cirdtOr anti \l\e 
chemical cleavage reaction, generaUng the f>tenii)iial amino acid 
thiohydantoin derivaUve (indicated as a circle) and the shoilejred 
peptide. 
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Fig. 3, Det(iih>d rcartlnn i;chejiie of Lhe HP Lhiohyttotoki C-terminal 
ac?q^]f^ncing t!hf*mjstry. The diemical coupling reactions wiiit dip he- 
nyl phoBphciryllsolhiocyanate (DPFITC) genenile li niijied tmiiydrlde 
foliowed by tiie extnssion of phosphatt? with ring fcirrnation to yiekl 
Lh€? peptide thiohydajiloiii. Tlie subsequerit rheniit-a! cleavage reac- 
tion with palassliirti triniethylsllandate (KOTMS) rele^se«> the C-tt^r- 
niiMal rmiino acid thir>hydantoixi derivative (TH-aa) from the short- 
ened peptide. 

The peptide Ihiohydantoin, bearing the chemically modified 
C*terminaJ amiriu a(nii, is fleaved with trlmethylsllanolate 
(a strong micleopitilic biise) to release tlve C'-temilnal thio- 
hydantoln-amltK) a<*id (TH-aa) derivative for subsequent 
analysis and the shortened peptide for the next cycle of 
chemical sequetKing, The thiohydantoin derivative of the 
C-ienuiiial amino acid residue is ciiromatographically de- 
tected and identified by HPLC analysis at a L'^' wavetength 
or260mn. 

Data Analyi^JK ^nd Interpretation of Resnlt.^i 

The tiaia aiiaiysis telitss uti tlie itvtetiirefatlou <jf HPLC chro- 
matogi-aijhic data for the detection and identification of tbio- 
bydantoin-aniiiio arid derivaU%'es. The se<^uencuig system 
iises the HP C-hiMitSiatiun suftwiu'e for aiitcuuatic data pro- 
cessing and repon general ion. By c(>nventi(Jii, the amino 
acid sequence is detennined from the successive single 
amino acid residue assignments made for each secpjencer 
cyt^le of analysis beginning witb the f-lenninal rcsidiu^ (I lie 
first se(|uencer cycle of analysis). The thiohydanloin-iunino 



add deri\^tive at any given sequencer <rycle is assigned by 
\isua!ly exanuning the succeeding cycle (n+1 1 and pn^ceding 
cycle (n-lj chromaiograms with respect to the cj'cle in 
question fn). The comparison of p^ak heights (or widths) 
acm^ three such cj cles typically enables a particular thio- 
hydanioin-amino acid derivati\-e to be detected quantita- 
tively, rising above a background le\'el present in the preced- 
ing cycle, niaximizmg in absorbance in the cycle mider 
examiiiaiioa and decreasing in absorbance in tlie succeeding 
cycle. Exceptions to this most basic algorithm are seen m 
sequencmg c*ycles in w hich there are two or more identical 
amino acid residues in consecutive cycles and for the first 
sequencer cycle, which has no preceding cycle of analysis. 

An HPLC* chromatographic reference standard consisting of 
the twenty conution amino acid thiohydantoin synthetic 
standards defines the chromatographic retention time (elu- 
tion time) for ea£:h particular ttiiohydantoin-amino arid de- 
ri\'arive. The TH-aa derivatives chromaiographirally detected 
in a sequencer cycle iirc identified by comparison of their 
chromatographic retention times with the retention times of 
the 20-componem TH-aa derivatives of a reference standard 
mixture. The practical assignment of amino acid residues 
til sequencing cycles Is contuigent on an increase in peak 
absorbance above a background leve4 followed by an absor- 
bance decrease for a chiomatographic peak that exhibits 
the same chromatographic retention time as one of the 
tw^enty tiiiohydantoin-amino avid reference standards. A 
highly robust chromatographic system is required for this 
mode of analysis to be reliable and reproducible. 

The chromatogi-aphic analysis of the onhne thiohydantoin- 
ajnino acid stand^ird niixUire is shown in Fig. 4. Tlie peaks 
aiT designated by tlie single- letter codes for each of the 20 
common amino acid residues (see page 74) and corresiK>nd 
to approximately 100 picomoles of each thiohydantoin de- 
rivative. Ttte thioliydantoin standard mixt.itre is composed of 
the sequencing producis of each (jf the amino acids so that 
Ser aitd Cys amino acid derivatives each resuh m t.lte same 




15 20 25 

Relentroe Tints tniin| 

Fig. 4. HPLC ctirornatograrii i if the thioliyrinninifi aniino acid 
standard imture (TH-f^td). TIm? thiohydaiitoin-aiiiino acid 
dotivatlves <jf the ( orrin^on aniiiio acids are iiuliiiated by their 
Single-letter code rlesignations (see page 74). The peak ideriti- 
fifKl asS/C represcinls the thiohydarttoin fierivativp of senile 
m)ti cysteiiie. The peak tles^naf ed D' repr<?senls the nit^thyl 
ester sequent-ing product of aspartic acici ;md the E' peak 
represejits tiie methyl cst^r sequencing tfi^^^fluct of glutairiate. 
Isoleiiclne, desljEjnated I, ehites as two chroinatographically 
resolved slereoisonieric Ihiahydantoiii derivatives. 
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compouiid, designated S/C, which is the dehydroalaniiie 
thioliydantoin-ajniiio acid derivative. The peaks labeled D' 
and E' signify ihe methyl esters of the tliiohydaiitom-aniino 
at-id derivatives of Asp and Glu, 

The C-tenninal iirotein sequencing system is conilgured 
with the IIP Gli)09A protein sequencer which automates the 
chemical sequencing, the MP I090M HPLC for the riuomato- 
graphic detection and identification of the tliiohydantoin- 
amino acids, and an HP Vectra personal computer for instru- 
ment control and data processing as shown in Fig. 5, Tlie 
chemical sequencer coiLsists of assemlilie.s of chemically 
resistant, elecuically actnaterl <iiapliiagm valves comiected 
tlirough a fluid path of men tubing that permit, tile precise 
deliveiy of cheniiciil reagent.s and solvents. The fluid delivery^ 
system is based on a timed ijressimzation of reagent and 
solvent bottles that directs the fluid floW' tlnongh dehver^^ 
valves (inclnding valve manifolds) into the fluid path. The 
sequencer control sofl ware functions on a Microsoft^^ 
Window s platfoim and features an extensive user-interactive 
graphical interface t^or instirnnent control and histnuneut 
method editing. The sequencer data analysis software is a 
modified version of the HP ChemSt^tion software with 
featiu'es specific for the analysis and data reporting of the 
thiohydantoiu-amino acid residues. 

Sample Application to Zitex Membranes 

Tlie sequeucing chemisti>^ occms on Zitex reaction meuv 
braiies (inert porous membranes), wMch are housed in Kel-F 
(inert perfluorinated plastic) sequencer reaction colmnns. 
The Zitex membrane senses as the sequencing support for 
the coup! nig and cleavage reactions. The membrane is 
chemically inert to die sequencing reagents and retains the 
sample through multipoint hydrojihobic interactions during 
the sequencing cycle. The chemical methodology perfoinied 
on the Zitex membrane enables the sequence analysis of 
proteins and low-molecular- weight peptide samples. The 
secjuenccr saiTiple reaction coknnns are installed in ;my one 
of four available sequencing sample positions, which sen^e 
as temperatme-controlled reaction chambers. In tliis fashion, 
four different samples can be independently programmed 
for automated sequence analysis, 

C-terminal sequence analysis is readily accomplished by 
directly apphiiig the protein or peptide stmiple to a Zitex 
reaction membrane as diagranuued in Fig. 6. The process 
does not require an.v presequenciitg attachment or coupling 
cheniLstries. The basiCt acidic, or hydroxj^lic side-cliain 
amino acid residues are not necessarily subjected to any 



Tig. 5. The HP (ilf)tl9A C-lenniiial 
protein yequeiifung system coiisLsrs 
of the HP C-Lernitnal sequencer, 
the HP 1090M IIPLC, and an HP 
Vectra computer 



presequencing chemical moditl cations or derivatizations. 
Conseriuently, there are no chemically related sequencing 
ambiguities or chemical inefficiencies. Protein samples that 
are Isolated using routuie separation procedures invohdng 
various buffer s>'sten^s, salts, and detergents* as well as 
samples that ai'e prepared as product fonnulatioits, can be 
directly analyzed usmg tJiis tectmique. The chemical method 
is universal for 'Any of the 20 common amino acid residues 
imd yields riiioiiytlantoin derivatives of serine, cysteine, and 
threonine — all of which frequently appear in protem C- 
I ettninal sequences. 

To be successfitl, the sequence analysis must provide immn- 
biguous and definitive amino acid residue assignments at 
cycle 1, since all x)rotein forms— whether they result from 
internal processing, clippings, or single-residue tiiincations — 
are available for analysis at that cycle in their relative pro- 
poitions. 

New Sequencing Applications 

The He wletT- Packard G 1009 A C-terminal proteui sequencing 
sj^stem is capable of performing aji expanded scope of se- 
quencmg applications for the aiTalysis of peptide and protein 
samples prepared using an aiTay of isolation imd purification 
techniques. Tl^e recently inti'oduced version 2,0 of tJie HP 
tiiiohydantoin sequencing chemistry^ for the HP GlOO! fA C- 
tenninal sequencer now supports both the "high-sensiti^Tty" 
sequence imalysis of protein samples recovered hi 50-ro- 
lOO-piccnnole amounts attd an increase in the number of 

1 . Zitex memliraneisifeateilwfthalcohi^t 

2. Sample sof uti mi is dir^qtlY app I led \<i meinliiaii e a nt) a 1 1 owe d to d ry. 

3. Membrane is Inseitad tnto a sequencer colifmn. 
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Fig. 6, Proceduie for saiupie appMcation (loading) onic* a Zitex 
C-temiinal sequencing membrane. 
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sequenceable cycles. The hi^i-sensithity C-tenninal seqtience 
anal>'sis is contpatible wnh a great ^-aiietj- of samples en- 
coiintered at these amount levels in research laboratories, 

C-cerniinal sequence analysis of protein samples recovered 
from SDS (sodimn dodecylsylfaie) gel electrophonsis is an 
important application enabled by the high'Sensiti\it^^ se- 
quencing chemistr\*. SDS gel electrophoresis is a routine 
analytical technique based on the electrophoretic n^obility of 
proteins in gel matrices. The techniqne provides information 
on the degree of overall sample heterogeneity by allowing 
individual protein species in a sample to be resolved. The 
sequence analysis is performed on the gel-resolved proteins 
after the phj^cal transfer of ihe protein components to an 
inert membrane, such as Teflon, using an electrophoretic 
process knov^Ti as eleetroblotting. SDS gel electroplioresis 
of native ajid expressed proteins frequently exhibits muJriple 
protein bands indicating sample heterogeneity or internal 
protein processing — both of critical concent for protein 
characteJization and production. 

TJie combined capabilities of high-sensithity sequence analy- 
sis and sequencing from SDS gel electroblots has enabled the 
development of tandem N-temiiual aiul C-ternunal sequence 
analyses oit single samples using tire HP G10(J5A N-terminal 
sequencer in combination uith the HP G1009A C-temiinal 
sequencer. This procedure unequivocally defines the protein 
N-temiuiaJ and C-teiniinal aniino acid residues anti the pri- 
maiy^ structural integnr>- at both termini of a single sample, 
thereby eliminating n\ultiple mialjtical methods and any 
ambiguities resulting from sample4o-santple variabihty. 

C -Terminal Sequence Analysis Examples 

The first five cycles of an automated C-tenninal sequence 
analysis of hon>e heart apomyoglobin ( 1 nimotnole) are 
slu.mii in Fig. 7. The unaruljiguous result observ-ed for cycle I 
confinus Iht* nearly complele homogeneity of the samjile. 
since Jio signitlr lun adthiional i hiohydtmtoin derivatives can 
be assigned at tlmt cycle. The analysis continues clearly for 
Vivi^ cycles enabling the amino acids to be assigned with 
high confidence. The results of a sequence analysis of 500 
pii'ornoles of reromlunanl irUtTfenHt are slu>wn in Fig. 8. 
Tlie first five cycles show the unamtiiguouH sequencuig resi- 
due assignments for Ote C-termlnal amino acid sequence of 
the protein product. 

The results of a C-teniunjiJ sequence analysis of 1 nanomole, 
10(1 picomoles. and 50 piconioles of liovine Ijeia-lactogloljulin 
A a]'e shr>vMi ui Fig. 9 as the cycle-1 ilPLC chroniatograms 
obtained for eat h of the respective sample ainounLs. Tlie 
recovery for the first cycle of sequencing is approximately 
40% to W'^ (based on the amomits apphed to the Zitex mem- 
bratves) m\d an approximately lijiear recovery is observ^ed 
across the rajige of sample amount. Tlie linear response in 
the detection of the f hioliydantoin-amino acid sequencing 
products imd a sufficiently quiet chenncal l>ackground j>er- 
mit the high'Sensitivity C-terminal sequence analysis. 

The automated C-lemiinal sequencing of the HP GIOO^A 
C-terminal sequencer facilitated the detection and identillear 
tion of a novel C-tenninal modificatioti observed for a class 
of recombinaiti protein molecules eXT>ressed in E. coli that 
has compelling biological implications. I)r, Richai'd Simpson 
and colleagues at the Ludwig Institute for Cancer Research 
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Fig, 7, Cycifjs 1 to t^ of C-temunal sequtfuring of 1 naiiQmole of 
hoTSf' apomyoglobin. 
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Pig. S* Cycles 1 to 5 of C-tentiiiial spquej icing of 500 picomales of 
r£'C(jnibinmit beta-interferon applied to Zitex (230 picomolea of Am 
recovered in cyckf 1). 
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Fig, 9. C-berminal seqtieneo analysiii of boviiie beta-kctoglobiilm A 

across d 20-l"old range of sajnplp amoiint, 

m Melboumei AiistraJia reported the identification of a pop- 
ulation of C-temmial-tnmcated foniLs of niuriae iiilerleukin-t) 
molecules reeotiibiiiantly expressed m E. colj thai bear a 
C-termmal peprule exteasionJ Fig. 10 shows the resuhs of 
the first five cycles of a C-tentiinal sequence analysis of a 
purified fomi of C-temiinal-processed uiterleukin-6 identi- 
fying the amino acid sequence of the C-tenninal-app ended 
peptide as Ala(l)'Ala(2>Leu(3)'AlaC4)-'IVr(5}, 

High- Sensitivity C-Tenninal Sequence Analysis 

Protein samples in amomits of 50 picomoles or more are 
applied in a single step as hqiiid aliquots to isopropanol- 
treaied Zitex reaction membranes. The san^plcs disperse 
over the membrane surface where they are readily absorbed 
and immobilized. Tlie dry sample membranes do not usually 
requiie waslung once the sample is applied even in those 
cases where buffer components and salts aie present. As a 
rule, the matrix components do not interfere witJi the auto- 
mated chemisti'y and are eliminated during riie initial stetis 
of the sequencmg cycle. 

Fig. 11 shows the unambiguous residue assignments for the 
first three cycles of sequence analysis of a 50-picomole sam- 
ple of ho\1ne beta-lactoglobulin A applied to a Zitex mem- 
brane. Again, the linear response ui tjie detection of the tliio- 
hydantoin-amino acid sequencmg products coupled with a 
sufficiently quiet chemical backgi ound enable Mj^h -sensitivity 
C-terminal sequence aiu^lysis. Tlie sequence analysis of 
50 picomoles of human seiami albumin is shown in Fig. 12. 
The chromatograins perniit clear residue assignments for 
the first tluee cycles of sequencing. 
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Fig. 10* (Jycles 1 to 5 of C-teritiiitaJ aequencing of recambinant 
murine interleukin-H identifying the C-Lermiiial exl.ension peptide 
(AALA\^ iis described in the text. (1 nanomole applied to Zitex: 
55& picomoles of Ala recovered in cyde h) 

C- Terminal Sequence Analysis of Electroblotted SDS 
Gel Samples 

Analytical gels are routinely used for tlie analysis of protein 
samples and reconU>inant products to assess sample homo- 
geneity^ and the occurrence of related forms. The comn^on 
obsei-vation of several closely associated protein SDS gel 
bands is an indication either of cellular processmg events or 
of fragmentations induced by the isolation and purification 
protocols. Because of its capacity to ped'omi high-sensitivity 
analysis, C-tenuiniil sequence analysis provides a dii'ect 
characterization of these various protein species and facili- 
tates the examination of their origin and control. 

Li collaboration with scientists at Glaxo WeOcome Research 
Laboratories, Research THangle Park, North C'aroUna, SDS 
gel eiectroblottuig procedures have been developed and 
applied to protein samples of divei'se nature and origin.^ 
Topically, 50-picomole (l-to-lO-microgram) sample amounts 
aie loaded intcj individual SDS gel lanes and separated ac- 
cording to molecukir weight by an apphed voltage. Following 
electrophoretic resohition of the protein samples, the protein 
bands on the SDS gel ar^e electroblotted to a Teflon mem- 
brane. The electioblotted proteins, \isuaiizeti on the Teflon 
membrane after dye-stainuig jirocedures, are excised in the 
proper dimensions for insertion directly into C-terminal 
sequencer colmnns as either suigle bands (1 cm) or multiple 
bands. The visualization stain does not interfere witii the 
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Fig. 12. High-sensitivity C-teraiiiMl isequendng of 50 picomotes 
rif htimaj; seruirt albuniiii indieaiirig approximately ?tB% recoverj^ 
(28 picomoles) of cycle I leucime 
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Fig, 1 1. HifiJi-sensitiv^ty C-teimliial sequ^tcing of 50 picomoles 
of bovine beu-laetojglobulm A intlicating approxinmtely 60% 
recoveiy (24 picamoles) of cycle- 1 isoleiicine, 

' sequenre aimlysis aiid thp e*xcist*d bands do not have l.o he 
treated with aiiy extciisive w^lsIi protocol before ^(juentung. 

Pig. 13 shows the results of sequence analysis of approxi- 
mately 250 picotnoles of a bovine «erum albimiin (08 kDat) 
sample loaded into one lane of the SDS gel, subjecled l.o 
electrophoresis^ and electxoblotted to a Teflon membrane. 
The chromalograins for cycles 1 to 3 of the j^ingle i-ctti pro- 
tein band stHiuenceti from the Teflon cIectrot>lot illusirate 
the high sensitivity of the sequencing technique, hi Fig. 14, 
approximately 50 picomoles of a phosphodiesterase (4^3 kDa) 
sample were apphed to an SDS gel lane, subjected to electro 
phoresis, electroblotted to Teflon, mid excised as a single 
1-cni sulforhod£unme-B-siainetl biincL C-tennmal sequence 
nnalysis of the Teflon blot cnaljlcd fbe determination of the 
extent of C-tenninal processiJig its demonstrated by the 
presence in cycle 1 of the Ser expected from tiie full-lengtii 
form, in addition to the His residue arising from a j^rotein 
form exhibit inj^ the tmncatian of the C-terminal amino acid, 
in about a 10:1 ratio. The expetned full-lengtli C-tcnninal 
sequent!e continues in cycle 2 (His) and cycle 3 (Gly), v^ith 
the tmncaled form yielding Gly in cycle 2 and (jIu in cycle 3. 
Additional processed protein forms also are identifiable. 

1" kDa = ktlodaflDfis. A dalfon i@ a unit ot ma^s .measufemsni tpprtncimaiely gquai to 1 ,66 x 
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Fig. 13* C-lermina] f^eQiience anuiy.si.^ of 250 picomoles of 
Ik nine senini rdhuniiii apptied tn uti SDS gel^ ek'f'troblottfKl to 
Teflon tape, and suiy^eited to three cycles of analysis, 70 pito- 
iuuleis of Ala recovered in cycle 1. 
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Fig, 14. Cydes 1 to 3 of a C-lenrtirLai sequence imaJysjs of 50 

picoriioles of phosphodiester^e eiectroblotted frorn ai^ SDS 
gel to TefToii tape. Three protein sHpecies are irJentified at 
cycle 1 of the sequence anajysis mdiGatmg protein C-terrmnal 

processing of the sample. 
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Fig. 15, Cycles 1 Lo 3 of a C-terniiiial sequence analysis of polio viral 
capski protein, \T2, elect roblottc^d from an SUB gd to Teflon tape. 



This application was exploited by researchers at the Depart- 
ment of Biological Chemistry of the University of California 
at Irv-ine to m% estigare the C-iei n^inal ajTiino acid sequences 
of polio virus capsid proteins aj\d examine additional vin^ 
systems. ^^ Polio \iral capsid proteins VP2 and \T3 were 
electio blotted to Teflon tape from SDS gels for C-tenninal 
sequence analysis. Figs. 1"> and IG show the results of the 
sequence analysis, which unanibiguously identifies the C-ter- 
minai residue in both proteins as Gin, witJi atlditional ajnino 
acid residue assignniejits lieing Gln(r)'Len(2)-Ai'g(3) for V'P2 
and Ghifl )-Ala(2)-Leu(3) for \T3 subunits, respeetively. 

Tandem N-Teniiiiial and C -Terminal Sequence Analysis 

The attiino acid sequence analysis of both die N4er minus 
and the C-terminus of single protein samples enables aniino 
acid sequence identification at the respective terminal ends 
of the protein molecule in addition to a rapid and reliable 
detection of ragged protein termini. The tandem sequence 
analysis prfjcess of N-temiinal protein sequencing followed 
by C-temiinal protein sequencing of tlie same single sample 
provides a cojnlnned, unequivocal technique for the deter- 
niination of the structural integrity of esqiressed proteins 
and biologically processed precursors. Tire analyses are 
perfonned on a single samjjie of protein, thereby eliminating 
m\y ambiguities that might l>e attnbuted to sample-to-saniple 
variability and sample preparation. 

The protein sample is eiUier applied as a Oquid volume onto 
a Zitex membrane or electrobiotted to Teflon from an SDS 
gel and inserted into a membrane-c^ompatible N -terminal 
sequencer cokmm. Tiie sample is subjected to automated 
N-terminal sequencing using the HP G1005A N-terminal 
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Fig. 1 6-, Cycles 1 to 3 of a C-teiTnirial sequence atiaJj^sis of polio viral 
capsid proteiTL, VP3, electrobiotted from an SDS gel to Teflon tape. 
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Fig. 17. (a) Cycles 1 to 5 of ari N-termirtal sequence analysis of 250 picomoies of horse apornyoglobin electroblotted from aji SDS gel to 
Ti^fltjn rape. The HP GIQOSA N-temttrral sequencer wa^ used to sequence the sample applied to the Zitex mc'mbrane. 47 picomoles of Giy 
recovered at cycle 1, (b) Cycles 1 l:o 'i oftjip C-temiuial siequence analysis of the N-termlnai-seqiienced nTyoglobin sample of Fig. 17a 
subjected to (^terminal sequencing using thii HP (ilOO^M C -terminal sequencer. The sample membrane was directly transferred from the 
HP G1005A N-lemiinal se<iueftcer to the HP GUJOfJA (%temmiai sequencer. 79 tiicnmoley of Gly rt^coveretl at cycle 1. 



protcnn sequencer. Tlie siiniple menibrane is stibstHiitently 
trans feiTed to a C-Cenuinjil sequencer CDlunitt mul subjeried 
to automat eci C-temiiniU sequence iuuilysts u^ing the HP 
G1(M)9A (Merniijial protein sequencer hi this lasliioti, a 
single siitnple is analyzed by both st(*quencjng proiot ols, 
resulting in .Htniciural infonnathm I hat jiertains prec isely to 
a given poi>uialion ofproleins.-' 

Figs. 17a and 17b demonstrate the tandem scjquencing proto- 
col on an SDS gel s^miple of honse myoglobin. About 2^Q 
picot^ioles of myoglobin were applied to ajt SDS minigel 
across five laites, subjected to eiectrophoresis, and electro^ 
blottt^d to a Tefloti ntetiihrane. Five sulforho<iamine-B-staijted 
l>anfis were excised tmtl inserted into the \-tenuin^il se- 
fjnencer cohmm. Five cycles <*f N-temiinal sequencing iden- 
tified the sequence Gly(l>Leu(2}-Ser(3}-Asp(4}-Gly(5j witli 
47 i>icoiuoles of Gly recovered at cycle 1 as shown in 
Fig. 17a. The sequenced Teflon bands were transferred to a 
C-tenninai sequencer coluniii and the resuhi* of Fig. 17b 
show the expected C-terinimU setjuence fily(3)-GlnC2)- 
Phe(3) with 79 picomoles of Gly ret-overed at cycle 1. The 
HP tiiiidem sequencing ()roto<T)l is currently being empioyetl 
to afjcertain the primari^' structure and sample homogeneity 
of piiamiaceutical and biotechnology [>rotein products in 
addition to protein systems under active study in acaderaic 
resear c^h 1 ab oral ories. 



SuuHiiary 

Tlie HP GlOfJfiA C-terminal protein se<|iieneer generates pep- 
tide ^uid protein C-tenuiniil mnino acid sequence information 
on a wide viiriety of sample tyi>es and sample preparation 
teclmiques. including low-level sample amounts ( < 100 pico* 
ntoles). HPLC fractions, SDS gel electrohlotted samples, and 
stmiples dissolved in various buffer sojut ious ^uid furmula- 
tJons> The automated sequence analysis |>rovides unambigu- 
ous ajid tiefmitive amino aciti residue itssigmtients for the 
first <*yele of sequence analysis and enables additional resi- 
due assignments for typically three to five cycles, lite ability 
to sequence through any of the common amino acitl rt^sitlues 
provides researchers with a critk^al compotient for reliable 
setiuence identification. The tandem process of N-termitiai 
mid C-tenninal sequence analysis of single protein samples 
pro\i{les a significant solution for the evaJttation of sample 
homogeneity and protein processitig. ITu* utility of these 
current applicatiorts is being applied to the investigation of 
many protein systems of importmice itt biochemistry and in 
the development inid c liaracieriz^itlon of proteui fiierapeutic^. 
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Measuring Parasitic Capacitance and 
Inductance Using TDR 

Time-domain refiectometrY (TDR) ts commonlv used as a convenient 
method of determining the characteristic impedance of a transmission line 
or quantifying reflections caused by discontinuities along or at the 
termination of a transmission line. TDR can also be used to measure 
quantities such as the input capacitance of a voltage probe, the 
inductance of a jumper wire, the end-to-end capacitance of a resistor, or 
the effective loading of a PCI card. Element values can be calculated 
directly from the integral of the reflected or transmitted waveform. 

b\' DaAid J. Dascher 



Why would anyone use TDR to measure ai\ mductance or 
capacitance when Uiere are many inductaiice'Capacimnce- 
resi stance ( LCR) meters available that have excellent reso- 
lution and are easy to use? First of all, TDR allows nieasure- 
ments lo t>e made on dexices or structm'es as they reside in 
the circuit, Wli*^n nveasuiing paiasitic quantities, the physical 
surroLuidings of a device may have a donunani effect on the 
quantity tliat is being measured, [f the measurement cannot 
be made on die de\ice as it resides in the circuity then the 
measurement may be invalicL Also, w^hen measuring tiie 
effects of devices or structures in systems contaiiimg trans- 
mission lines, TDR Jillows the user to separate tlie charac- 
teristics of the ti'^ismission hues from the chai^acteristics of 
the de%icc or stnicture being mt^^istiri'd withf»ut pliysically 
separating anything in the circuit. To illustxate a case where 
TDR can directly measure a quantity that is very difficult to 
metisure with an IX-R meter, ctjosider the following example. 

A printed circuit boaj-d has a long, narrow trace over a 
ground plane, which fonns a inif rostrip transmission line. At 
some point, the trace goes from I he (op of the print efl circuit 
board, through a via, to the bt.)tt(.>m of the primed circuit 
board and continues on. The ground plane has a small open- 
ing where the via passes Uvrougli it. Assuming that tlie %ia 
adds capacitance to ground, a model of this structure would 
be a discrete capacit;inc<" to grtumd between the lop and 
bottom transmission lines. For novt', assimie that die charac- 
teristics of the transmission lines aiT known and all that 
needs lo be measureci is the value of capacitance to gromid 
between the two traivsmission hues. 

LIsuTg an LCR meter, the total capacitance between the trace- 
via-trace strut^ture and ground can be measured but the 
capacifance of the via cannot be separated from the capari- 
tance of the traces. To isolate tlic via from the traces, tlie 
tiaces are removed from the board. Now the ( apacitance 
between just the via and ground can bv mcasuied. IJnfotlii- 
nateJy, tlie mea.sured value is noi the correct value of capaci- 
tance for the model. 

Using TDR instead of an L(.'R meter, a step-shaj>ed wave is 
sent down the trace on the printed circuit board imd the 



wave that gets reflected from the discontinuity' caused by 
the via is obser\-ed. The amoimt of '"excess" capacitance 
caused by the via can be calculated by integrating and scahng 
the reflet ted waveform. I'sing this method, the measured 
value of capacitance is tlie correct value of capacitance to 
be used in the model. 

The discrepancy betw^een the two measurements exists 
because the LCR meter w^as used to measure the total ca- 
pacitance of tlie via while TDR was used to measure the 
excess capacitance of the via 11^ the series inthjctance of the 
via were zero, then its total capacitance would be the same 
as its excess capacitance, Suice ttie series indtictance of the 
via is not zero, a complete model of die via must include 
both its series inductance iuid its sinml capacitance. Assum- 
ing iJiat tlie vui is capacitive. the complete model can be sinv 
plified accurately by rt^movirig the series inductant^e and 
including only the excess capacitance rather than the total 
capacitance. 

ft shoiiiti be no surjirise that the value of excess caijacitanee 
measured using TDR is the correct value for the model Tlic 
reason to model tJie ti-ace-via-tmce structure in tiie first placp 
is td predict what effect the via will have on signaLs propa- 
gal J rig along the traces. TDR propagates a signal along the 
trace to make the mcjisuremenL In this sense, TDR provides 
a direcl measurement of the unknown iiuantity. 

To deriv^e expressions that relate TDR waveforms to excess 
capacitance and inductance, an understanding of fundamen*^ 
tal transmission line jnu'aineters is required. Tliis article 
presents a cursory review of transmission lines ^md tlie use 
of TDR to characterize them, and then derives ex|>ressions 
for excess capacitance and inductance. If you are already 
familiiu- witti transmission Imes and TDR, you may wish to 
skip tlie review sections. 

Fundamental TVansmission Line Parameters 

First, a k-w w<jnls about "grountt" 'fwin-k^ad lor Iwisted-pair) 
wire forms a two-conductor tnuismission luic structure thai 
can be modeled as shown in V\g. I . The model includes the 
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Fig, 1. T^vo-coiidLit'tor traiisniissio!i llups aiid lurtvpeci LC raotlels. 

self-inductance of each conducton mutual inductance be- 
tween the seir-iiuiuclmires, and capacifttnce between the 
two conftuctors. Skin Hlect and (Jieiecl ric loss lire assumed 
to Idp negligii^le in this model. Iiijecting a curreni trarisitnit i 
into one side of the transTnission line^ from node A I to nofle 
C'l^ causes a voltage v = iZo to appeal' between nodes Al taut 
CI and also causes a voltage v = Ldi/dt to appear across the 
series inductance of l>oth ttie A-B and t'-D conductors. 
Relemiig back to (he|>l;yskal slnieture, this means that 
ttiere is a voltage diJTejence between the left side and the 
right side of eacli conductor, liven if you ntmie the C'-D con- 
ductor "ground," it still develops a voltage between its left 
side and its right side, across its series inductance, 

Mirroslrip iraces and coaxial rallies fcoax) me two sj^ecial 
cases of two-ronduttor transmission line stnictures. Iryect- 
ing a ciu'rem osmsient into one side of a mit rost ri[j or coax 
transmission Une causes a voltage to appear across only one 
of the two conductors. In the case of an ideal niicrostrip, 
wliere one of the conductors is infinitely wide, the vtide 
conductor can be tJiought of as a coiuluclor ^vitii zero induc- 
tance. Hent^e the \T>ltage generaletl across I he infinitely 
wide conductor is zero. With coax, the induct^uice tjf the 
outer conductor is not zero. However, tiie voltage generated 
across the inductance of the outer conductor lias twi) com- 
ponents. One componeni is a result of the currejU through 
the self 'inductance of the outer conductor (V| = Uj^tli/f^t). 



The other component is a result of the cunent through tlie 
center conductor tmd the nuitual inductance between the 
center antl outer conductors ( V2 = Lj,|di/d1 ). Cement that 
enters the center conductor returns througli tlie outer con- 
ductor, so tlie tw^o currenls are equal bui m oppt>site diiec- 
tions. The unique propeity of coax is that the self-induc- 
tance of the outer conductor is exactly equal to the mutual 
indactajice between tlie center and the outer conductors. 
Hence the two components that contributr^ lo the voltage 
generated across the inductance of the outer conductor ex- 
actly cancel each other atKl the resulting voltage is zero. 
WTien cLurent is iryetii'rl into a coax iransmissifin line, no 
voltage is generaletl altaig the outer condnrior if the current 
in the center condneior is returned in the outer conductor. 

The point here is that the generahzed nuxk^l for a two- 
conductor ti-aiLsnussion tine can be simphlled for niicrostrip 
and coax constnic-tions. Tlie simplified model has zero in- 
ductance in series witli one of the conductors since, in both 
caseSj no voltage apjiiears across the conductor. This con- 
ductor is commonly refened to tis the ground plane in micro- 
strip transmission lines and as the shield in coax trtmsmission 
tines. The other conductor, the one that develops a voltage 
across it Js refened to as the transmission hue, even though 
it is really only half of Uie structuie. 

There are iw<j ways to model a lossless transmission line. 
One nielhod defines the transmission Une m terms of char- 
acterisiic impedmu^e (Zo) and time delay (tti) aiul the other 
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Fig, 2, Tvvt) LC mode^ls for a coaxial cable The nve-segmFni model 
is ^ifenryU' over a wider range of frequencies tiiJUi tiie one-seginent 
model 
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method defines the transmission line in tenns of total series 
induetance (lirr^Tal) ^^^^^ ^oi^ shmit capaciUintie ( t'TotaL)^ There 
aie times when it is beneficial lo tltink of a traristiijssion line 
in terms of Zq and i(] and likewise, there ai'e times when 
thinking in terms of Ciotai ^i^ LtouJ ^s best. 

If one enci of a long transmission line is driven with an ideal 
ciurent step, the voltage at that end will he an ideal voltage 
step whose height is proportional to I he ciin'ent aiKl die 
characieristie impedance Zo of the transmission line: Vi,^ = 
ki^H) The waveform generated at that end will propagate 
along the trans miss ion line and anive at the opposite end 
some time latei\ The tJmt* it takes the wave to propagate 
from one end to iJie ottier is d^e dme delay (t^^) of the tTans- 
niission line* 

The total eaparttance anrl indiietanre of a transmission line 
can be measuretl with an LCH meter. To determijie the total 
capacitance of a coaxial cable, measure the capacitance be- 
tween the center conductor and the shield at one end of the 
cable while tire otiier end is left open. The fret^neney of the 
test signal used by d^c LCR meter should he much less than 
l/(4t(|) where t^i is the time delay of the cable. To me^isure tlie 
to1:al inductance of tlie cable, nie£isure the uiductance from 
the center conductor to the shield at one end of the cable 
while the other end of the cable has the center conductor 
connected to the shield. Again p die test frequency must, be 
much less than l/t4td). 

If the characteristic impedance and lime dehiy of a iransniis- 
sion Ime are known, then the total shunt capacitance atid 
total series inductance of the transmission line can be calcu- 
lated Bs: 



Zo 



^TotaJ 






td 



If the total shunt capacitance and total series inductance are 
kntywn, then Z^ i\\n\ 1^| can be calculated as: 



As an example, rtiany engineers use 50-olini coaxial cables 
that iire atjoui four feet long and have BNC connectoi's on 
each end. The tune delay of these cables is about six nano- 
seconds, the capacitance is 6 ns/50 ohms - 120 picofarads, 
and tiie uiductanc;e is (i iis x 50 ohms = 300 nanohemys. 

Fig* 2 shows two LV models for a 50-ohm» 6-ns-long coaxial 
cable. The distributed inductance of the tnmsmissifjn line 
has been collected into two disciete inductors in the first 
model and six discrete mductors in tJie seconti model The 
distriliuted capacitance has been collected into one discrete 
capacitor in the fust model mid five <:hscrete cfipjiciixjis in 
the second. t'oUecdng the distributed capacitance and m- 
ductance into disciete, Imnped elements reduces die range 
of frequencies over which the model is accurate. Tlie more 
discrete segmenLs there are, die wider the rmige of fi'equen- 
cies over which (he mo<lel is accurate. Fig, 2 shows tlie mag- 
nitude of the impedance seen looking into one end of each 
model while the other end is left open. The five-segment 
intHiel is accurate over a wider range of freciuencies than the 
one-segment model. 

Fig. 3 also shows the tninsmitted response tfuougl^ eacli of 
the models In a circuit that is both source and load termi- 
nated in 50 ohms. The discrete LC models are both low-pass 
filters. Again, the five-segment model is accurate over a 
wider range of freijuencies than the one-segment model In 
the time dnniaiii, a good rule of fluimb is to bjeak a trans- 
mission line into five segments per rise lime. For example, 
to build a model tiiat will accurately simulate the response 
of a step with a 1-ns rise time, the model should contain five 
segments per nanosecond of time delay. This %vcjuld leqtiire 
a 30-segment model for the 4-foot» 6-ns coaxial cable- 
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The transimssioE line model used in SPICE and many other 
t]nne<lomam simulators is defined by characteristic imped- 
ance and time delay. It consists only of resisiorSj dependent 
sources, axid time delay. It is an accurate model of a lossless 
transmission line over an infinite range of frequencies. There 
are three situations in which lumped LC models may be pre- 
ferred over the Z^-tf] model used by SPICE, Wlien modeling 
very short sections of transmission Unes, the maximum lime 
increment is never greater tlian the time delay of the shortest 
transmission Une. Short transmission lines can cause lengthy 
simulations, Wien modeling sidn effect and dielectric loss, 
discrete LC models can be modified to include these effects. 
And fmally; discrete LC models can be used to model trans- 
mission line systems that contain more than two conductors. 

Characteristic impedance and time delay, or series induc- 
tance ai\d shunt capacitance, completely specify the electri- 
cal properties of a lossless transmission line. Pro]iagation 
velocity and length are also required to specify a physical 
cable or printed circuit board trace completely. If the time 



delay (also known as the electrical length) of a cable is 6 ns 
and the physical length of the cable is 4 feet, then the propa- 
gation velocity is 0,67 feet per nanosecond. The propagation 
delay is 1.5 ns per foot. 

Reflection Coefficients for Impedajice Changes 

Fig. 4 shows a typical mesLsurement setup using a:i oscillo- 
scope with £m internal TDK. Tlie oscUloscope input is a 
50-ohm transmission Une termuiated in 50 olmis, Tl\e TDR 
step generator can be modeled as a current source that con- 
nects to the 50-olmi ti-ans mission line between the front of 
the oscUloscope and the 50-Qhni termu\ation. When tlie cur- 
rent source transitions from low to high at time - 0, voltages 
are generated in the system as shown. Note that the upper 
traces in Fig. 4 are plots of voltage as a function of position 
along the transmission lines, not time. The waveform 
\iewed by the osciUoscope is the wavefomi at the 5t)-ohm 
tennination, which is shown at the bottom of Fig. 4. This is 
the TDR waveform. 



trisO-ZBris ti = Q2Bm td = til» 
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There is only one discontiiiuity in the system: the transition 
between the 50-ohni cable and the 75K3hni cable at node F 
When the wave propagating along the 50-ohn\ transmission 
line arrives at the 75-ohni transmission line, reflected and 
transmitted waves are generated. The wave thai is incident 
on the transition is shown at time = L2 ns. Waves that are 
reflected and transmitted from the transition are shown at 
time ^ L3 ns. Defming a positive reflected wave to be propa- 
gating in die opposite direction from the incident wave, the 
reflected wa^'e is given asi 



reflected 
incident 



Zb 



2b + 2a ' 



where Za is the characteristic impedance through which the 
incidenl wave travels and Ze is tlxe characteristic impedance 
throiigli wiiich the transmitted wave travels. The transmitted 
wa\e is given as: 



transmitted 
kicident 



2Z 



B 



2b + Za ' 



If Za = 50 ohms, Zji = 75 ohms, and the incidenl wavefonn is 
a IV step, then ttte reflected waveform will he a step of 
lieight 1(75 - 50J/(75 + 50 J = 0.2 volt, and the transnutted 
waveform will be a step of 1(2 x 75y(75 + 50) = 1.2 volts. 

It is important to note that the wavefonti that appears at 
node F is the waveform thai is transmitted into the 75-ohm 
cable. Tlie waveform at node F can be deri\'ed by simplifying 
the circuit at the transition. Looking hack mto the 50-ohm 
caiile, the eircnir can he modeled as a voltage som'ce in series 
with a resistor. The somce is t^ace the voltage of the step 
propagating along tiie 50-ohm cable and the resistor is the 
characteristic impedance of the 50-ohm cable* Looking inl<> 
tlie 75-ohni cable, the circnit can be modeled as a 75-ohm 
resistor. The simpiifled circiiil is jtisl a voltage divider in 
which the divided vollage is 2VstepZ2/(Z2 + Zij ^ 1.2Vstep- 
This Ls the transmitted wavefonn. 

The TDR waveform, the waveform at the 50-ohm termina- 
tion of the oscilloscope, is shown at the bottom of ¥\g. 4. 
The incident step is showni at time = 0.25 ns and the re- 
flected step is shovtTi at time = 2.75 ns. The characteristic 
impedance of tlie Zu-c^lnn transmission line Ccai he calculated 
from tlie TDR waveform by soiving for Z^^ in the above rela- 
tionship, which gives; 



Zh = Z 



/ incident + reflected \ 
^\ incident - reflected / ' 



Botii the incident m\6. reflectecl waveforms aje stej) functioiLs 
that differ only in amplitude ^ind direetion of propagation. In 
the expression for %b, Llie step hmcrions cancel aiitl all that 
remains is the step heights. Tlie TDR wavefonn in Fig. 4 
shows the incident step height to be +1V and the reflected 
step heiglvt to be +0.2V. Knowing that the impedance looking 
into the oscilloscr>pe is Za^ = 50 ohms, the chj^iracteristie im- 
pedance of tJie secor\d cable, Z^, vm^ be calculated as Z\\ = 
50(IV + 0.2V)/(1V - 0.2V) = 75 olmis. 

There is a "transition" between the front panel of the oscillo- 
scope and the first cable. The characteristic impedance on 
either side of the tninsitjon is the same, so the reflected 
wave has zero unijiliiudt^'. If I here js no retlected wave, the 
Irajisjiiitted wave is idenlical (o the inrideni wave. Electri- 
caUy, tliere is no discontinuity at. this transition since it 



cau^s no reflection and the tiansmined wave is identical to 
the incident wave. 

The transition betw^een transmissiDn lines of different charac- 
teristic impedances is a discontinmty tltat produces reflected 
and transmitted waves that are identical in shape to the inci- 
dent wa%'e. The reflected wa^e differs from the incident wa\'e 
in amplitude and direction of propagation. The transmitted 
wave differs only in amphmde. Discontinmdes that are not 
simply impedance changes will produce reflected ^id trans- 
mitted waves that are also different in shat^e from the inci- 
dent wave. 

Discrete Shimt Capacitance 

Fig. 5 shows two 50-olmi transmission lines vkith a shunt 
capacitor between them. The capacitance produces a dis- 
continuity between the two transmission lines. A wave that 
is incidenl on the discontinuity produces reflected and 
transmitted waves. In this case, both the reflected and trans- 
mitted waves have a different shape than the incident wave. 

Given an incident step, the voltage at node H can be ascer- 
tained by simplifying tjie circuit as sho\^ii hi Fig. 5. The mci- 
dent step, shown at tinie =1.8 ns, has an amphtude of inc_ht 
and is propagatirig alonga 50-olmi transmission line, Looking 
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Fig. 5, Two 50-ohm T.mnsniissloii lines wijJi a shtntt capacitor 
bt^twcen ritPiii. Tht* f-apacitfliice C is to be nteEisured. 
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to the left of the capacitor, the circuit can be simplified as a 
voltage source in series with a resistor. Tlie voltage source 
is twice the incitient voltage and the resistance is Zo = 50 
ohms (not Rs = 50 ohms). Lot>king to the right of the capaci- 
tor, the circuit can be simplified as a resistor of value Zf) = 50 
ohms (not Rl = 50 ohms). The simplified circuit contains no 
trimsmission lines. Tlie circuit can again be simplified by 
combining the two resistors and the voltage souice into their 
Thevemn equivalent. 

Note that if the left transmission hne did not have a source 
rests tiir\ce of 50 olinis or the riglit transmission line did not 
have a ioafi resistant e of 50 ohtns, the simplified niocicl 
would still be valirl for 4 ns after (he incideuT. stei> arrives at 
node H. After 4 ns, reflecticjns from tlie s(jurce and load ter- 
minations would have to be aceoimted for at node H. 

Looking at I he simplified circuit and redeluimg tune = to 
be the time when the incident step anives at node 11, the 
voltage at node H is zero for tune < 0. For time > 0, the 
voltage at node H is: 



Jit(l- b-t), 



vn = mc 



vt^here t = RC — -^ C . 

The vohage wavefVirm that appears on node H is the trans- 
mitted w^aveform. The rellt^cled wave can he deterjuined 
knowing that the incident wave efjuals tlie transmit tetl wave 
plus the reflected wave (defiiiuig each wave as positive in its 
own direction of jDropagation), For time < 0, the reflected 
m ave is zero. For time > 0, the reflected w^ave is: 

reflected = -iiic_h1 ■ e~T, 



Normalizing Uie reflected waveform to the incident step 
height anci integrating the normalized reflected waveform 
gives: 



reflected n 



reflected 
inc ht 



1 



reflected n ■ flf 






rdf 



Sohing for the shimt capacitance between tlie I wo transmis- 
sion lines gives: 



2t 






reflected n ■ dt. 



where t 



RC 



Thus, the amount of <'apacilance between the two tnursmis- 
sion Imes caii be detemiijied by integrating and scaling the 
noiTuahzed reflected wave form. 

Rg. 6 shows a measured TDR waveform fi-om a 50-ohin 
niicrostrip trace with a rliscrete capacitor to groimd at the 
nuddle of the trace. Tlie TDR waveftjmi lias l>een normal- 
izefl to have an uicicleni step heiglu of L The TV)H wavefomi 
shows the incident step at 0.15 nanosecond and the re- 
flected wave superimposed on the incident step at 2.3 nano- 
seconds. Tlie reflected wave can be ascertained from the 
TDR wavefonn to be the TDR w^avefomi minus one for all 
time after the incident step has settled. The bottom trace is 
the integral of the normalized reflected wavefomi scaled by 
-2/Zo = -1/25. Mathematically, the reflected wavefonn needs 
to be integrated until time = inflnity, but piactictillv the re- 
flected wavefonn only needs to be iritegraled imlil it has 
settled reasonably close to zero, hi this case it takes about 
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Fig. 6. (top) Measured TDR wave- 
romi from a 50-oluii niicrosirip 
trace m\\\ a disfrpte tapacilor to 
ground at tJie middle? of the I rare. 

(bottom) The integral of the re- 
flected w^weform revels thni t)ie 
capacltaune is 2.t) pF. 
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500 picose<*onds for the reflected wave to settle. The bottom 
trace shows thai the discontinuity is a 2,0-pF capacitance* 

Hg. 5 shows an ideal reflecied wave to be an exponential 
with the sante heigtit as the incident step, but Fig. fi shows a 
measured reflected wave to be similar to an exponential bni 
with a rounded leading edge and a heiglil much less than 
(hat of the tiie incident step. Tlie measured reflected wa^e 
dtflers Ironi the ideal reflected wave bec^ause of tlie nonzero 
rise time of die incident step and loss in the transmission 
liaes. Neither of tliese nonideal conditions affects tlie inte- 
gral of the refiected wave, as will be shown later. 

Discrete Series Inductance 

Fig. 7 shoves two 50H:>hm transmission lines with a serieis 
inductor betw^een theni. Given an incident step, the circuit 
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Pig. 7. Two fSfUjliin transmissiiin Urns wiLh a ,^erles inductor 
between llif ni, Tlif^ indtii'laiicf^ L is in bf tiieasiirod 



can be simplified as shown to determine the voltage wave- 
forms at nodes J and K. Tlie voltages at nodes J and K are 
zero for lime < 0. For time > 0. tiie voltages at nodes J and 
Kare: 



vj = inc_hl 



where t 



VK ^ ine 

L 



_ht|l - e4j 



22o^ 



In the previotts cas^ of a shorn capacitor* tliere was only one 
node betw^een the t^vo transmission lines at which the rela- 
tionship incident = transtnittefi -h reflected was applied. Now 
there are two nodes, eac:h of which has unique incident, 
trajxsmitted, aiid reflected waveforms. The voltage wave- 
form at node J is the wavefonn diat is transmitted to the 
inductor and the voltage waveform at node K is die wave- 
form that is tnmsmitted to the riglit tnmsinission Une. The 
wavefonn that Ls reflected at node J is the iitcident wave- 
form mi mis the waveform trans initted to tiie inductor, that 
is, vj. 

For time < 0. the retletted wave is zero. For time > 0, the 
reflected wave is: 



reflected 



inc ht ■ e T. 



Normalizing the refleftetl waveform to the incident step 
heiglit and integniting the normalized reflecte<l waveform 
gives: 



reflected_n 



reflected 
ht 



mc 



= T- 



rene(Med_n ■ tit = e uM - -j.e~ 



Solving for tlie series inductance between the two transmis- 
sion lines gives: 



L = 2Zot = '3Zu ieflecLed_n - dl . 



Tlujs. 1 he amount of inductance between the two ti-ansmis- 
sion lines can be detennined by integrating and scaling the 
nonnalized reflected waveform. 
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Excess Series Indue ten ee 

In the previous two cases of shunt capacitance and series 
induclancej the ciiscontinuity wiis caused by discrete^ luiT\ped 
capacitance or inductance. Discontinuities can also be caused 
by distributed shunt capacitance and series inductance. 
Consider the printed circuit board tiaces shown m Fig. 8. 
Being over a ground plane, die traces fomi microstrip trans- 
mission lines. Tlie circuit can be modeled as two long, l-ns, 
50-ohm transmission lines separated by ashortj lOO-ps, 
80-ohiu transniLssion line. Modeling the disco ntuiuiti^^ as a 
short, liiglT-impedance transmission Une produces accurate 
simidatdons up to very high frequencies, or for incident 
wavefonns with very fast transitions. 

Tlie discontinuity ran also be mocteled as a single discrete 
inductor Modehng the discontincjity as an inductor pro- 
duces less-accuiate sininlations ai high frequencies* but 
when transition times are much larger than the time delay of 
tlie discontmuity, a simple inductor produces accurate sinui- 
lation results. The simpler model provides quick insight u^to 
the beha\ior of the circuit To say a thscontinuity looks like 
4.9 idl of seiies inductance pnmdes most people widi more 
insight dian to say it looks like a lOO-ps-k>ng, 80-ohm trans- 
mission line. Also, simulating a single inductor is much faster 
than simulating a very short transmission line. 

The total series inductance of die 100-ps-long, 80-ohm trans- 
mission lij>e is: 

LToiiti = I'd 2 High - 100 ps X 80 ohms = 8 nH> 
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Fig, 8, T\vo 50-ohjn tiucrosirip transmission lines with a distnbuteci 
dlscontiniiitJ' between them. Tl^e discontinuity can be modeled as a 
short 80-okni triinsinlasion line or (less arcnrately) as a series 
indnttor. The correct inductance to be used to model the iiarrow 
trace is Lexcrss- Of the discontinuity were mnch wider than the 
50-ohm traces, instead of luirrower as shovsTi here, il could be 
modeled as a shunt capacitor.) 



To model the short trace as an 8-nH inductor would be in- 
correct because the trace also has shunt capacitance. The 
total shunt capacil^ance of the trace Ls: 



Ct, 



dUil 



^High 



IQO ps 
80 ohms 



= L25 pF, 



To simpJiiy the model of the discontinuity, separate the total 
series mdnctance into I wo pails. One part is the amoimt of 
indoctance that wouki combine with the total capacitance to 
make a section of 50-olim transmission hne, or "balance" the 
toti^ capacitance. Tlie remaining p£ul Ls the amount of induc- 
tance that is m excess of the amount nccessaiy to biilance 
the total capacitance. Now, combine the total capacitance 
with the portion of the total inductance that balances that 
capacitance and make a short section of 50-ohnr transmission 
hne. Pm this section of transniission Une m series with the 
remaining, or excess, inductance. The short 50-ohm trans- 
mission iine does nothing except increase the time tielay 
between the source and load. The excess inductance (not 
the to till inducttmce) causes an incident wave to generate a 
nonzero reflected wave and a nonidentical transmitted wave. 
This is the correct amount of inductance to use to model the 
short, narrow trace. 

In this case, the portion of the total inductance that balances 
the total capacitance is: 



Bfilaiif 



e -^ ^ Tot.nl ^t) 



1.25 pFx (50 ohms)- = 3.125 nH 



and the remaining^ excess inductance is: 

^Excess - ^Jtm] ~ ^Balanc^i^ 

- 8 nil - a 125 nil = 4.875 nlL 

Expressing the excess inductance hi tenns ol' tbe time delay 
aiid impedance of the narrow trace (td, ^mgii) attd the im- 
pedance of the surrounding traces (Zo = Xgfi) gives: 
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Wig, 9a shows TDR waveforms from a SPICE simulation that 
compare the reflection generated from m\ ideal 4,8S-nlI in- 
ductor to the renecHori gei^erated from iin 80-ohm. lOO-ps 
tran^n\ission line, both iri a 50-ohni system. P'ig. 9b shows 
TDR wavefonns of the smtie circtiit as Fig. 9a, but the rise 
tune of the incident step in Fig. 9b is longer than the rise 
tune used in Fig. 0a. Notice Tlial when the rise time of tiie 
inciilent step is much laigei' tlian the time delay tjf tlie dis- 
continuity, the sunplifled model agrees witli tJie transmission 
line model /\s the rise time of the mcident step chmigcs^ the 
peak value of the reflected waveform also changes but the 
integial of t he reflected wavefoim does not change. Usii^g 
the mtegral rather than the peak value to quantify the dis- 
continuities makes the measiu-enient of excess inductance 
rise time mdependent. 
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Fig- 9. (a) TDR tvaveforms from a SPICE simulation sliowiiig 
reflectiorta from an ideal 4.88-rLH inductor and an 80-ohin, lOO^ps 
traufliniHSsiGn line, both In a 50-ohm system. The fmal value of ihe 
integml of th(f* reflpeted wav^ is the smne for both, (b) f^aiiie a.=i (a) 
for an inridt/'nt step with a longer rise time. Tht* agreemfmt between 
the reflected w^ves for the single- iiidiietor mcKiel aixfl the trans- 
mission line is better. The final value of the ijitegjal of liie reflected 
wme is tmchanijed, 



The leaigth of the transmi^on line to the ri^t of the discon- 
tinuity has no effect on the reflected or transmitted \va\'e- 
forms since it is terminated in its characteristic impedance. 
It has been shown as a long transmission line so the trans- 
mitted wave can be viewed easily. If the right transmission 
line is remo\"ed then the discontimut>^ is at the termination 
of the left traiLsmission line. QuanTif>1ng parasitic induc- 
tance and capacitance at the tenninadon of a transmission 
line is no different from quantifying parasitic inductance and 
capacitance along a transmi^on line. 

Non.'50-Olim Zn^f 

Often, the impedance of the sj^stem to be measured is not 
the same as tlie impedance of the TDR/ oscilloscope system, 
Tliere are tw'o ways to deal with non-50H3hm systems, Fiistt 
the TDR can be connected directly to the system to be mea- 
sured. Second, an impedance matching network can be in- 
serted betw^een the TDR and the system to be measured. In 
either case, the above relationships cat^ be applied if correc- 
tions are made to the TDR wavefom^. 

Coimecting the TDR directly to a non-oCk>hm system, as 
shown in Fig. 10, creates a s>'stem with two disco niinuities» 
one being the transition between tiie 50-ohm TDR and the 
nom50-ohm system aiid the other being the disf^fjntinuiiy to 
be measured. The incidetu step will chmige amplitude at tiie 
non-50-ohtn inteiface before arriving at the discontinuity' to 
be measured. The reflected w^ave from die discontimiity 
creates another reflection w^hen it arrives at the non-50-ohm- 
to-SO-^lmi interface. This secondary^ reflection propagates 
back into the non-50-ohm system aiul generates smother 
reflection when it iirrives at the discontinuity being mea- 
sure d. If twice the time delay of the transmission line be- 
tween the non-50-ohni interface and the discontinuity beuig 
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Excess Shunt Capacitance 

in the example shown in Fig. 8, the discontinuity is a section 
of trace that is nanuwcr llian the stii-ronndingtrac^. This 
discontinuity can be modeled as an imluclon If adisconlitm- 
ity is a section of trace thai is wider than the surrounding 
traces, the discontinuity can be modeled as a capacitor .^s 
in the previous case, the <:Tjrrect value of capacitaiK'e is not 
the total capacitance of the wide section cjf trace but rather 
the difference between the total capatitaiice and the portion 
of diat capacitance that combines witli die total inductance 
to make a section of transmission line of the same imped- 
ance as the suiTounding, reference impedance. In ternLS of 
the tune delay and imiiedancc of the wide trace (t^j, '^hnv,) 
aiid the impedance of the surrounding traces (Zo = ZR^f Jt the 
excess capacitance is: 
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Fig. 10. A TDR connected to a non-50-ohm traniiniission line with a 
capftcitanee C to be measured. There are multiple reflections. The 
discontimiity can be accurately quantified a^ long as the re fleet ton 
to be measured caji be isokited from other reflections on Oie TDR 

wavefomi. 



April 11)90 Hewleri-Pat^lsani Jtiiinial 91 



)Copr. 1949-1998 Hewlett-Packard Co. 



measured is laiger than the settling tmie of the first reflecteti 
wavT, then the integral of the normalized reflected wave can 
be evaluated fiefore any secondary retlectiuns anive. OtJier- 
wise, alJ of the seeondarj'* reflertinns must settle before the 
integral can be evahiated. If tlie discontiimity is purely 
capacitive or inductive, then the rereflections will not 
change the final value td which the integral converges. 

TVt o corrections need to he made to the TDR wavefomi. 
First, Uie hejglU of the step thai is incidem tjn Ihe discontinu- 
ity- inc_ht, is jiot thc^ sanie as the heiglil of die step tha! was 
generated by tlie 7DR, tdrjit. Second, the reflected wave- 
form that is \dewed by the oscilloscope, reflected^scope, 
lias a different niagnitude from the wavefomi that was re- 
flected from the disconlinuiiy. reflected. Tlie relationships 
between the chaiacterisiic inipedaiice of the system heing 
measured, tlte characteristic iJtipcdance of the TIJR, and the 
above waveforms are: 

incjit = tdr_ht= ^ 

_, . 2Ztdr 

reflected_scope = refleetedT^^ — = — . 

^TDR + 2rp1 

The characteristic impedance of the system being measured 
can be calculated from the heiglit of the step reflected from 
the transition beti^ een the 50'Ohm TDR system and the 
non-50-ohm (2^^i) system, ref l_lit. 
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To calcidate series inductance or shunt capacitance, the 
integral of the waveform reflected froui the discontinuity, 
nonnaJized to the heigtti of tlie step incident on the disconii- 
nuity, needs to be evaluated. In terms of the measured TIJR 
wavefomi, the normalized reflected waveform is: 



reflected^n = ^^^^ 
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As an example, the shunt capacitance would be: 
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Reflections between the discontinuity and the non-SO-ohm 
transition can l>e removed if an hnpeihmce rtiatcfiing net- 
work is inserted i>etween the IDU and the non-50-ohm sys- 
tem. Two resistors are flie niininmrn requirement to match 
an impedance transition in both directions. Attenuation 



across the tnatching network needs to be accounted for be* 
fore integrating the reOecled wavefomi. UTien a maichiug 
network is used, neither the impedance of the system Ijeijig 
tested nor the attenuation of tiic matching network can be 
ascertauied from the TDR wavefonn. If lnm_12 is the gain of 
the matching network going from the TDR to the system and 
fian .21 is the gain going from the system to the TDR. tlien 
tlie normalized reflected waveform is: 
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Series Capacitance 

So fm\ all of die discontinuities that have been measured 
have been nieic ijcrturbations in the characteristic imped- 
ance of transmission Ime systems. The discontinuities have 
been quantified by analj^ismg the reflected waveforms using 
TE>R. Now consider a situation where a capacitance to be 
measmed is in series with two transniLssion lines, as shown 
in Fig. 11. The series capacitmice can be quantified using the 
transmitted wavefoi"m rather thmt the reflected wavefomi. 
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Fig. 11, A series capacitance between two transmission lines can 

l.)i-^ mea.^iirc'd using tiie transnYttted wavelbmi CUme-doniain 
rniusmisslon or TDT) ratlier than TlJR. 
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or using time'd0main tvansmissioH (TDT), Given an inci- 
dent step that arri\'es at the series capacitance at tinie = 0, 
the transmitted wavefomi is zero for tiine < 0. For time 
> 0, the transmin€?d wavefomi is: 



tiar^mitted = inc ht - e" 



where 



t = H€ = 3ZoC. 



Note iJtat t is now proportional to 2Zii instead oTZi/2, 
Normalizing tlie rransntitled wavefomi to the incident step 
height and iniegrating die nonnaiized. transniitted wave- 
form gi^'es: 



transmitted n ~ 



tnmsniitted 
inc ht 



HKos 4- « 

I transmitted_n ■ dt = I 



_ I _ ^ 

e 1 * dt = -Te " T 



Sohing for the series capacitance gives: 



2Zo 2Zo J 



transmitted n - dt. 



Shnnt rnductance 

The last topology' to be analyzed will be shunt inductance to 
ground. Given an incident step that arrives at the shunt iii- 
diictancc at time = 0, the transmitted waveform is zero for 
time < 0. For time > 0, the tnmsmitted wavefomi is: 



tiansmitted = inc ht - e" 



where 



(2(,/2) 



2L 



This is the same transmitted waveform as in the case of 
series capacitance, x is 2L/Z(), so the sliunt inductance isi 



2o 2o r 



transmitted n - dt. 



^ L Iwfe woyld affect the irrtegral. 
ZfisSOoliins 
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Fig. 12. L aiid K m series with a shuiit rapacitatice da not aEfect 
the meiisui ement of C. 



More Compiex Discontinuities 

Cf insider a ciiciiit in which a tiansniission Line Ls luougtit to 
the input of an integraled circuit (TC) and terminated 
(Fig. 12). Looking from llie tenuination intcj the IC, there 
migtit be iiiductajice of tho lead in series with a dampmg 
resisl^ice in series with the input capacitance of the K.\ 
A Orst'Orrler ap proximal ion of the load that the IC puts on 
the termination of the li^uisiuission line is simply a capaci- 
tor The reflected wave ran he integrated to c^ilciilale the 
cat>acitanee, i)iit will the series intiiictance and resistance 
change tlie measiu'ed valne? Looking back to Fig, 5, the cur- 
rent into the shunt capacitor is: 

2inc ht t ^ ■? 

I = — 5— e t = -reflectea;^-. 

The integral of the reflected wave is directly proponional to 
the integral of the cuiTent into tlte capacitor This means 



thai file value of capacltaiice calculated from integrating the 
reflecied wave is proponional to the total charge on the 
capacitor Resistance or influctance in series with the shiuit 
capacitor does not change the final value of cliiuge on tlie 
capacitor Hentve, tiiese elements do not change the mea- 
sured \'alue of capacitance. Series resistance decreases the 
heiglit and increases the settling time of the reflected wave. 
Series inductance superimposes ringing onto the reflected 
wavefomi. Neither changes the final vtilue of the integral of 
the reOected wave. Note ihai inductance in series with the 
trans mission line, as opi)osed to inductance in series with 
the capaciior, will change the measured value of capaci- 
tance. Similariyj vi^hexi measuring series inductance, resis- 
tance or capacittmce in parallel with the series inductance 
does not change tho measured value of inductance. 
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When buildmg a model for the input of the packaged IC, 
integrating {he reflected wave provides the correct value of 
capacitance for a single capacitor model ajid also for higher- 
order models. If, for example, a higher-order model contains 
a section of transmission iiiie teniiinated with some capaci- 
tlve load, then the value of capacitance nieasiired is the total 
capacitance of the transmission line plus tJie load. To ascer- 
taiti values for L and R iji Fig. 12, a more rigorous at^alysm of 
the TDR waveform must be performed. 

Now consider a situation in which a voltage probe is used to 
measure signals 021 printed circuit board traces. Wlial effect 
does the probe have on signals that are propagating along 
the tiaces? To a first-order approximafion, the Load of a 
high-impedance probe will be capacitive and the value of 
capacitance can be measured by mtegrating the reflected 
wave. However, son^e passive probes that are optimized for 
bandwidth can also have a significant resistive load (these 
prcjbes usually have a much low er capacitive load dian high- 
inipedaiice probes). Looking at tlie reflected wave m Fig. 13, 
the resistive load of the probe introduces a level shift at 
4 ns. The level shift adds a ramp to the integral so that the 
integral ttever converges to a final value. To measure the 
\alue of capacitance, the mtegral can be evaluated at two 
different times after the reflected w^ave has settled to its 
final value, say at 6 and 7 ns. Since the reflected wave has 
settled, the difference between the two values is caused 
only by the level shift. Tlie component of tlie integral result- 
ing fj oni the level shift can be removed from the total uite- 
gral by subtracting twice the difference betw^een tlie values 
at 6 and 7 ns from the value at 6 ns. The remaining compo- 
nent of the integral is a result of the shimt capacitance. 

Multiple Discontinuities 

Sometimes, lire transmission Lines betw^een the TDR/osciho- 
scope and t he discontinuity to be measiued are less than 
ideal. For example, the connection betw een a 5Q-ohni coax- 
ial cable and a 50-ohm printed circuit boaid trace can look 



Z^ = 50 ohms 



WQ 5 'd^^"^ 



Zo- 50 ohms 
tf| = Zns 




50Q 



Fig, 13, .A voltege probe used to measure signals on printed circuit 
board traces may act like a shuiit RC load, adding a ramp lo the 
integral of the reflected wave. 
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Pig. 14. Intermediatje disrontiniiities do not attectthe measurement 
a.s long as the discontinuity to be measured can be isolated on the 
TDR waveform, 

quite inductive if a short Jumper wire is used. Also, the sj^- 
tem being measin^ed may have more than one discontinuity, 

Intemiediate discontinuities between the TDR and the dis- 
contlnidty to be measured act as low-pass filters that in- 
crease the rise times of i>oth the inckient step and the re- 
flected wave. Intermediate dlscontiniiities also caiLse 
secondary reflections m the TDR waveform, as sho\\Ti in 
Fig. 14. If tlie discontinuity to be measured can be separated 
fro in siuToundmg discontinuities on the TDR wavefonn, 
then the discontinuity can be accurately quantified by mte- 
grating the reflected wave. Increasing the rise time of the 
system decreases any separation bel ween discontinuities 
but, as was shown earliei; does not cliange the integral of 
tJie reflected wave, 

Mmimizing Effects of Discontinuities (Balancing) 

There are many instances in which discontinuities in trans- 
mission line systems are unavoidable. Tlie effects of an un- 
avoidable discontmuity can be minimized by introducitig 
discontinuities of opposite polarity as close as possible to 
the imavoidable discontmuitj'. For example, if the narrow 
XJart of the trace shown in Fig. 8 is required, then the traces 
on either side of the narrow trace can be made wider to 
compensate for the excess inductance of the trace. Tlie 
annonnt of excess capaciiatice required to compensate for 
the 4.88 iiH of excess inductance is Z^L = (50 ohms)- x 4,88 
nH = 1.95 pR If the widest ti'ace that can be added has a 
characteristic impedance of 30 ohms, then 152 ps of this 
trace wiW add 1.96 pF of excess capacitiuice. Propagation 
delays on typical printed curuit board traces are around 
150 ps/mch, so adding 0.5 inch of 30-ohm transmission line 
on each sitle of I he narro\^' trace wiH balance the excess 
inrluctajice of tlie trace. B^ilancing the discontinLiit>' reduces 
reflections and makes the transmitted wave more closely 
resemble tlie incident wave. A discontinuity that is balanced 
w^ill produce a reflected! u ave whose iiitegial Ls zero. In this 
case, the integral of the reflected xvave can be used to deter- 
mine how well a discontinuity is balanced. 
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fiercer units. 



Fig. 15. Mpasuring ttip input 

capacitance of an HP 5470 L^ 
active probe by placing cursors 
arouiid the reflection caused 
by the probe. 



I na trumen tati on 

Hewlett-Packard recently introduced tJie HP 54 750 A oscillo- 
scope and the HP 54754A TDR plug-in. All of the measure- 
ments discussed above can be made by positioniiig two cur- 
sors on the TDR or TDT waveform. For TE>E, the position of 
the leftmost cursor defines when to start integrating the 
reflect etl wave and also detcmunes the reference imped- 
ance for the calciiiarion of excess L or C. The position of the 
rightmost cursor detennines when to stop integrating the 



reflected wave. Likewise, w^hen using TDT, the cursors 
determine when to start and slop uitegrating tlie transmitted 
wave. The oscilloscope calculates the integial of the normal- 
ized reflected or transmitted wave and displays the appro- 
priate value of capacitance or inductance, as shown in 
Mgs, 15 and 16. Parasitic inductances and (^apaciLimces can 
be accuratjely measttred in the time it takes to position two 
cursors. 



•Avos = 6^ 



Marker 




SO.O mU/div ISO iftii 



Mea^yred InduGUnee 



267,96? nU 1.9609 ns 

26a, 16^ flikf 2,6220 ns 
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Fig, 16* Mea.su ring tlip excess 
indue lance of a connector in a 
I tie rk er units,.. ^ f^^^'^^^^T^ system I jy placing cursors 
iutmml the refltHiioti catused by 
I he induclaiice. 
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Summary 

TDR can be usee! f.o mea.su re Impedances and discontinui' 
ties in trai\sniission line systems very accurately. Disc onti- 
nuities tJial are eitJier priniajily capackivc* or primarily iji- 
ductive can be accurately modeled by a sinj?le element 
whose val[je caJi be detenu iiied by i[U eg rating the reflocted 
or transmitted waves. In 50-ohnT systems, the integral of the 
nQrmalke<l rellected wave is simply the tinie constant of the 
network. 

Discontintiities ci:in also be qiitmtificd in terms of the peak 
value of the reflections they generate- The problem witli 
usiitgthe peak vakie of die rellection is that the value de- 
pends on the rise time of tlie incident step and the loss of 



the iransmission hue system between tlie TDR and the dis- 
continuity, llsuig the integral of die reflectefi wave io quan- 
tify a discontinuity makes the measurement independent of 
the rise time of the incident step and also inilependent of 
discontinttities between the TDR and the disconliiutity being 
measured, as long as the discontumily being measururi can 
be isolated from surroiuiding discontiiiuities on the TDR 
wilveforrn. 
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outdoor activities soch m hiking, camping, and golf 
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55 CDE Test Suite 



Kristann L Orion 

engineer at HPs TechnicaJ 

ComouTfng Center at 

■ Kfts^sm OrtDfi IS 
nvestjgeting 3D 

gre|ir,i£s middleware tooHttts 

fof use by iSVs (independent 
:ftw3re vendors) and cus- 

■-^mErs in the MCAD arM3 
ECAD markets She |oiT>etl HP m 1992. after complet- 
ing a BS degree In cojnputer science 3! the UnEversitv 
of (^lifomia, Santa Barbara When she first came to 
HR she worsted on the Motif de^ebprnent team, then 
moved to a team formed to automate the vatidation 
of HP's release software. Afterwards, she became 
one of HP's representati\/es on the joint COE test 
team. She worked on the joint devetepment and im- 
plementation of tiie testing framework, oversaw test 
engineers, and ensured timeiy deiiverabfes Before 
coming m HH Kristann worked as a securities trader 
in an investment coiinseling firm in Santa Sarbara. 

Paul R. Ritter 

Paul Rirter earned a OS de- 
gree in computer science in 
1970from the University of 
Calitornia at Berkeley, where 
■. il^ ^.'^^^M he also worked at the Unh 
B 1|\*^' *^^^l ^^^^'^^^ ^P^^^ science lab 
By ^- u^^^ "l^veloplng application soft^ 
W\ '^tm[ ^ v-i-e for digital analysis of 

i_V_'^_^^ lemote sensmg imagery, He 

started work at HP as a contractor in 1989. He was 
hired by the Workstation Technology Division as a 
regular employee in 1993 and earned an MS degree 
m computer science from Orepn State Universitv the 
same year. He is currently a software tievelopment 
engineer at HP responsible tor X server support. 
Previously, he worked on testing of Motif 1 .0 and HP 
VUE 2.0, and recently helped rfeveiop the test suite 
for CDE I .Q He has authored three papers, two on 
remote sensing algorithms and techniquBS and one 
on testing of Motif 1 .0. He is a member of ACM and 
IEEE. Born in Washington state, Paul is married and 
has one child. His hobbies include skiing, sottbalL 
and motorcycles, and he is an avid reader of fiction 
and nonf icbon books. 
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Sankar L Chakrabarti 

^^^^^^^ • ^rn in Azimganj. W. Ben^ 
^^^P^^^K :'. India, Sankar Chakra- 

^^H^^^^B .-i h received a PhD degree 

P^^^ -ic^ Y ' iiemistry in 1974 from 

^r ^ J ^s "fs^ Institute of Funda- 

W ^ r'W mental Research in Bombay. 

India In 1985 he received an 
MS degree m computer sci- 
ence from Oregon State Uni- 
vef^ity He joined HP's Portable Computer Division in 
1981 and is now a member of the technical staff at 
the Workstation Technology Center. He has worked 
on all aspects of the X Window System, has devel- 
oped tools for automating the testing of this system, 
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r -^ core tool used for 

l:. _ __:._! T dStingHecurrenttv 

is rESiJonsiQle fof i^ew technology ami processes to 
improve safiware tesfing and engin€€ring He has 
DutJiished sev^al papers on software testing, GUI lest 
tools. afKj pjogram specsftcation H€ ?s the winner of 
the 1992 HP Camputer Systems Organjzafion qtialitv 
and pfodyctivity award ana ts an mvrt^ speaker at 
conteances and unrvefsmes on l^ topn: of gottwa/e 
testing artd specsficauon Sanltar is marrted and has 
djvo children His wife ts an ink chemist at HPs Inkjet 
Supplies Business Onrt 

67 GSM Power Module 



Melanie M. Oanreb 

A hardware design engineer 
at HPs Communication Com- 
ponents Division since \W\. 
Melanie Darnels is currently 
working on ihe design. of 
base station amplifiers She 
was a design engineer and 
team leader for development 
of the GSM power module 
described in this issue. She has authored a paper on 
a 1-waTt low-cost power module, and her work on an 
ultralinear feed-fonA/ard base station amplifier has 
resulted m a pending patent. Before joming HP, she 
was a design engineer for modular components at 
Avantek. She was awarded a BS degree m micro- 
waves and RF in 1986 from the University ot Califor- 
nta at Davis and an MSEE degree in digital commu- 
nications in 1995 from Cahfornia State University at 
Sacramento. Melanie is married. In her tree time, she 
IS a member of ToastM asters and enjoys traveling, 
camping, and reading, 

74 Protein Sequence Analysis 

Chad G. Miller 

fA product marketing man- 
ager at HPs Cafifornra Ana- 
lytical Division, Chad Miller 
is GurFently rgsponstble for 
protein sequencing products. 
He has also served as prod- 
uct manager for the HP 
GlD09AC-terminal se- 
quencer and the HP G1004B 
protBjn chemistry station, and as an applications 
manager and applications chemast. He is profession- 
ally interested in protein chemistry, bioscience tech- 
nologies, and bio-organic chemistry. He is a member 
of the US Protem Society and of the American Asso- 
ciation for the Advancement of Science. He has pub- 
fished numerous articles in the past five years on 
protein sequencing and analysis and on C-terminal 
analysis. He received a BS degree Jn chemistry in 
197B imm the University of California at Los Angeles 
and an AM degree in chemistry in 1980 from Harvanj 
University Before coming to HP he worked at the 
Beckman Research institute of the City of Hope Med- 
ical Canter as a senior research associate m the Divi- 
sion of immunology. He joined HP's Scientific Instru- 
ments Divisioo in 1990, Chad is married and has two 
children His outside interests include creative writing, 
U.S. stamp collecting, backyard astronomy, and gour- 
met coffees. 
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Jerome M. Bailey 

Jerome Baife^ reeeivtd a BS 
degree in biochemistry m 
1982 from, the UnivefSit^' of 
Rochester and a PhO in 
chamistry m \%1 Jrom the 
Unrvs!3!ty of Oelawars 
Befere joining HP: hg was a 
tenure-track assisiam m- 
* ' ' searcf^ scieniist a! the Beck- 

man Research Instftyts of the City of Hope Msiicai 
Center for seven years His work fooised on protein 
SKjuencing chemistry and hardware He feft the Insti- 
tute and joined HP's Protem Chemistry Systems Divi- 
sion in 1994 As a research sctentist. he is currently 
responsible for C-terminaS sequencing of proteins arrd 
R&O, He IS professionally interested in en^ymology 
and protein characterization and is named as an in- 
ventor in twelve patents involving these areas of in- 
terest, especially C-terminal arKJ N-terminal sequenc- 
ing. He has also airthored and coauthofed numerous 
articles on these topjcs. He is a member of the Amer- 
ican Chemical Society, the Protein Society, and the 
American Association for the Advancement of Science, 
Jerome was born in Southing ton, Connecticui. He is 
married and has one child. 
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David J. Dascher 

J Dave Dascher graduated 

^ r"f om Colore do S tate U n i ve r - 

I sJty wFth a 8SEE degree. He 

f joined HP's Colorado Springs 
^ Division in 1984 as a hard- 

ware design engmeer. He is 
1^^ currently developing a high- 
\^^^ dansity analog probe system. 
"^^^ Previously he consulted on 
the HP &4754 TOR feature set and worked on the HP 
54720 oscilloscope ana log-to -digital converter (ADC) 
system and the HP S41 1 1 oscilloscope ADC. His work 
has resuited in four pending patents related to pnjbing 
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